Are you lacking an AWS useful resource in Terraform? Attempt awscc supplier!

There may be nothing extra irritating than operating into gaps in useful resource protection when working with Infrastructure as Code instruments like Terraform or CloudFormation. Not having the ability to use the most recent options to resolve a problem is demotivating. Lately, I found a approach to workaround lacking assets when working with Terraform. Within the following I’ll current the awscc Terraform supplier which is predicated on the Cloud Management API supplied by AWS.

What’s the Cloud Management API?

Every AWS companies gives an API to handle its assets. Infrastructure as Code instruments like Terraform make the most of the APIs to handle assets. However because the groups at AWS function independently, there was no normal in how APIs seem like, which comes with excessive upkeep prices. The Cloud Management API goals to simplify sustaining Infrastructure as Code instruments by offering a constant API to create, learn, replace, delete, and checklist (CRUDL) assets in a standardized manner.

AWS introduced the Cloud Management API in 2021¹. I keep in mind being upset by the announcement as a result of solely 366 assets had been supported again then². However issues improved throughout the previous three years: the Clod Management API now helps greater than 1000 assets. Even higher, AWS is including and increasing assets continuously.³

A Terraform supplier leveraging the Cloud Management API: awscc

The Terraform supplier awscc makes use of the Cloud Management API. The supplier is robotically generated primarily based on the Cloud Management API specification, which ensures adjustments have gotten obtainable in Terraform rapidly.

Utilizing the awscc is similar to utilizing the great outdated aws supplier. The next code snippet illustrates create an S3 bucket with the awscc supplier.

terraform {
  required_version = "~>1.0"
  required_providers {
    awscc = {
      supply  = "hashicorp/awscc"
      model = "~>1.0"
    }
  }
}

supplier "awscc" {
  area = "eu-west-1"
}

useful resource "awscc_s3_bucket" "demo" {
  bucket_name = "awscc-demo"
}

Evaluating Terraform suppliers: aws and awscc

What are the variations between the aws and awscc Terraform supplier?

As illustrated within the following desk, the aws supplier continues to be forward with regards to overlaying assets. However awscc is closing the hole step-by-step. Nevertheless, take into account that the comparability is counting assets and knowledge assets solely. It doesn’t take the depth of attributes of every useful resource into consideration.

The awscc supplier comes with a knowledge useful resource to checklist and get every useful resource. Nevertheless, it is advisable to present the IDs of the assets. There isn’t any approach to filter by some other attributes, as illustrated within the following instance.

For instance, the aws supplier permits us to fetch details about the default VPC.

knowledge "aws_vpc" "demo" {
  default = true # Filter the default VPC
}

In distinction, the awscc supplier requires the ID to fetch details about the VPC.

knowledge "awscc_ec2_vpc" "demo" {
  id = "vpc-b1123fd5"
}

So, the awscc comes with extra knowledge assets, however the lacking means to fetch assets by attributes apart from the ID limits their usefulness.

Is awscc forward of aws with regards to help new AWS options?

When working with Terraform, it’s irritating to run into lacking assets, hindering to make use of new options. So, I attempted to reply the query: Is the awscc supplier forward of the aws supplier with regards to supporting new options. I went via the GitHub problems with the aws supplier, searching for lacking options. Within the following circumstances, the aws supplier is lacking new assets whereas the awscc supplier already helps them.

Combine and match

The excellent news, you don’t need to resolve between utilizing the aws and the awscc suppliers. Simply use each, as illustrated within the following code instance, it’s easy to make use of each suppliers on the identical time.

terraform {
  required_version = "~>1.0"
  required_providers {
    aws = {
      supply  = "hashicorp/aws"
      model = "~>5.0"
    }
    awscc = {
      supply  = "hashicorp/awscc"
      model = "~>1.0"
    }
  }
}

supplier "aws" {
  area = "eu-west-1"
}

supplier "awscc" {
  area = "eu-west-1"
}

knowledge "aws_vpc" "demo" {
  default = true
}

knowledge "aws_subnets" "demo" {
  filter {
    title   = "vpc-id"
    values = [data.aws_vpc.demo.id]
  }
}


useful resource "aws_security_group" "demo" {
  title        = "demo"
  description = "Enable HTTPS."
  vpc_id      = knowledge.aws_vpc.demo.id
}

useful resource "aws_vpc_security_group_ingress_rule" "demo" {
  security_group_id = aws_security_group.demo.id
  ip_protocol       = "tcp"
  cidr_ipv4         = "0.0.0.0/0"
  from_port         = 443
  to_port           = 443
}

useful resource "awscc_ec2_instance" "demo" {
  instance_type      = "m5.massive"
  security_group_ids = [aws_security_group.demo.id]
  subnet_id          = knowledge.aws_subnets.demo.ids[0]
  image_id = "ami-0fed63ea358539e44"
}

Abstract

Add the awscc supplier to your Infrastructure as Code toolbox, because it helps to beat points with lacking assets within the aws supplier. Mixing the awscc and aws supplier isn’t a giant deal and value a attempt.