Contact Us
Python BlogDjango BlogBig DataSearch for Kubernetes AWS BlogCloud Services



Terraforming Parts Unknown: Strategies for Expanding Your Terraform Repertoire

March 12, 2021

Anyone using Terraform to increase repeatability/reliability of an infrastructure has experienced the need — and urgency — to deploy resources that are entirely new. Whether these resources are for a new product initiative, a client feature requirement or a personal project, below, I describe the process I use to work through challenges of deploying new-to-me resources.


Terraform's declarative, idempotent configuration syntax is a powerful tool for maintaining consistency while interacting with a single service provider. Resources from each service provider have distinct arguments, attributes and representation in Terraform's state. For example, there isn’t an abstraction layer that allows us to treat VM resources in AWS like those in Azure/Digital Ocean/VSphere. This becomes clearer when thinking about the unique service provider offerings.

To effectively use Terraform to manage any arbitrary resource, you need two of three things:

Let’s walk through my process for reaching a critical mass of familiarity with an otherwise mysterious resource. These approaches are roughly ordered by the time investment needed, rather than sequence. I expect each individual would follow a unique path, even if the end results were identical. The deeper the mystery, the deeper the search.

1. Read the Terraform Docs for the Resource

This is obvious, but I find the concise, consistent formatting of Terraform resource docs easier to read than the service provider’s. Sometimes a good example and the descriptions in the argument reference are all I need to get a first-draft config written and applied into a sandbox. Otherwise, I typically spend time bouncing through related resources.

2. Search It Up

This is usually the first instinct, and justifiably since the ever-expanding bounty of articles, blog posts and GitHub Gists can be invaluable, regardless of our experience in cloud computing, Infrastructure as Code (IaC) or traditional development/operations roles.

My advice:

3. Try It with the Service Provider's Tools

By thinking of Terraform as a wrapper around the service provider's API, it is clear that exploring their native tools can answer specific questions about the resource. This can also expose you to relevant aspects of the platform. Consider:

4. Build a Reference Prototype

The goal of this process is to explore the service provider and develop an intuitive sense of the resource. Once you have a strong understanding of the resource, you can build a prototype that fulfills one or two of the basic behaviors you're implementing.

Once you have a prototype, you can:

A few caveats to bear in mind:

Did I mention: never do this on production or any non-disposable environments!

5. Read the Service Provider Docs

Hey, where were these at when you were Searching It Up?


In-between investigation activities, it’s been useful to ask myself:

There isn’t any magic here, but hopefully there’s an idea that will help you when you're looking to fill the gaps. If there is, let us know! If I've left out some interesting approach or made a grievous error, I'd appreciate hearing about that too.

Tell us about the goals you’re trying to accomplish.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.