I recently - again - had to import resources to Terraform (0.11.14) from AWS that were outside of the default AWS region and were managed in a nested (non-root) module. The root module contained the provider configuration, including multiple aliases to allow creation of resources in different regions, as well as the nested module call, here in a very simple version:

provider "aws" {
  region = "us-west-2"
}

provider "aws" {
  region = "us-east-1"
  alias  = "us-east-1"
}

provider "aws" {
  region = "us-west-2"
  alias  = "us-west-2"
}

module "cloud" {
  param = value
}

The goal was to import some aws_ses_email_identity resources into the “cloud” module. So, originally the cloud module had this:

I’ve stumbled upon interesting access denied problems with S3-based Terraform state files recently. Suppose you have two or more Terraform root modules which use the same bucket for storing the state and just use a different key (=state file):

terraform {   backend "s3" {     bucket = "terraform-state"     key    = "root-module-1"     region = "eu-central-1"   } }

and

terraform {   backend "s3" {     bucket = "terraform-state"     key    = "root-module-2"     region = "eu-central-1"   } }

However, trying to access the state file in one root module works, but on the other you get a generic S3 Access Denied error:

I was recently bit by a feature (one might call it a bug) in Terraform. We wanted to try out the “Networks” feature in Hetzner Cloud but that required upgrading terraform-provider-hcloud, which in turn required upgrading Terraform to 0.12.x. For the most part migration from 0.11.x code to 0.12.x code was straightforward with some help from the automated migration tool. I even went as far as read some of the migration documentation, but missed one important part: connection blocks no longer have default values. To make the matter worse Terraform 0.12 does not error out if values are unset: instead if just runs the provisioner and then times out. This seems to be related to Terraform bug #21690.