Are you missing an AWS resource in Terraform? Try awscc provider!

There is nothing more frustrating than running into gaps in resource coverage when working with Infrastructure as Code tools like Terraform or CloudFormation. Not being able to use the latest features to solve a challenge is demotivating. Recently, I discovered a way to workaround missing resources when working with Terraform. In the following I will present the awscc Terraform provider which is based on the Cloud Control API provided by AWS.

What’s the Cloud Control API?

Each AWS services provides an API to manage its resources. Infrastructure as Code tools like Terraform utilize the APIs to manage resources. But as the teams at AWS operate independently, there has been no standard in how APIs look like, which comes with high maintenance costs. The Cloud Control API aims to simplify maintaining Infrastructure as Code tools by providing a consistent API to create, read, update, delete, and list (CRUDL) resources in a standardized way.

AWS announced the Cloud Control API in 2021¹. I remember being disappointed by the announcement because only 366 resources had been supported back then². But things improved within the past three years: the Clod Control API now supports more than 1000 resources. Even better, AWS is adding and extending resources constantly.³

A Terraform provider leveraging the Cloud Control API: awscc

The Terraform provider awscc utilizes the Cloud Control API. The provider is automatically generated based on the Cloud Control API specification, which ensures changes are becoming available in Terraform quickly.

Using the awscc is very similar to using the good old aws provider. The following code snippet illustrates how to create an S3 bucket with the awscc provider.

terraform {
  required_version = "~>1.0"
  required_providers {
    awscc = {
      source  = "hashicorp/awscc"
      version = "~>1.0"
    }
  }
}

provider "awscc" {
  region = "eu-west-1"
}

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

Comparing Terraform providers: aws and awscc

What are the differences between the aws and awscc Terraform provider?

As illustrated in the following table, the aws provider is still ahead when it comes to covering resources. But awscc is closing the gap step by step. However, keep in mind that the comparison is counting resources and data resources only. It does not take the depth of attributes of each resource into consideration.

The awscc provider comes with a data resource to list and get each resource. However, you need to provide the IDs of the resources. There is no way to filter by any other attributes, as illustrated in the following example.

For example, the aws provider allows us to fetch information about the default VPC.

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

In contrast, the awscc provider requires the ID to fetch information about the VPC.

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

So, the awscc comes with more data resources, but the missing ability to fetch resources by attributes other than the ID limits their usefulness.

Is awscc ahead of aws when it comes to support new AWS features?

When working with Terraform, it is frustrating to run into missing resources, hindering to use new features. So, I tried to answer the question: Is the awscc provider ahead of the aws provider when it comes to supporting new features. I went through the GitHub issues of the aws provider, looking for missing features. In the following cases, the aws provider is missing new resources while the awscc provider already supports them.

• aws_bedrockagent_prompt
• iot_job_template
• sagemaker_mlflow_tracking_server

Mix and match

The good news, you don’t have to decide between using the aws and the awscc providers. Just use both, as illustrated in the following code example, it is simple to use both providers at the same time.

terraform {
  required_version = "~>1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~>5.0"
    }
    awscc = {
      source  = "hashicorp/awscc"
      version = "~>1.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

provider "awscc" {
  region = "eu-west-1"
}

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

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


resource "aws_security_group" "demo" {
  name        = "demo"
  description = "Allow HTTPS."
  vpc_id      = data.aws_vpc.demo.id
}

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
}

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

Summary

Add the awscc provider to your Infrastructure as Code toolbox, as it helps to overcome issues with missing resources in the aws provider. Mixing the awscc and aws provider is not a big deal and worth a try.