In tandem with my recent post on Reusing Providers in Terraform, I used the example of working with the Terraform AWS provider. It may come as a shock, but it's because I was working on implementing some resources in AWS that we hadn't done much with in the past. Through this process, I learned a couple of things...

Regions Matter

Unlike other providers that I've used, it appears that regions are incredibly important to AWS. If you have a resource in one region and it's trying to contact or append to a resource in another region, you can run into all kinds of weird errors.

In one case, we couldn't use a resource in us-east-1 and have it connect to a resource in us-west-1 without it trying to do some redirect magic. So it's all well and good to be able to use the aliased providers, but depending on your dependency tree, it may just be best to put everything in one region.

Secrets Live

In other providers, destroying a resource sends it into the void. You say "vaya con dios" and then never think about that thing again.

This is mostly true in AWS, with the exception of Secrets Manager. When a secret is deleted, it has a default delay of 30 days before it is actually removed. So it's possible to remove the resource, have it no longer in your state or visible through the web console, but be unable to recreate the resource due to an existing resource with the same name.

It was only upon deleting a secret through the console that I learned about this.

Resource Linking

The last thing, and this is pretty fringe, was I ran into an issue with using resources in other resources. Specifically in the case of setting IAM policies on a resource.

This was kind of a silly thing and I was already not positive it would work, but the error handling wasn't great. I kept seeing an error on initialization of terraform that just said "cycle" and two resource names. It took me a second to figure out what it was trying to tell me.

Do with this what you will.

Just want to keep this out there for when I forget next week.