We are getting an intermittent error where Terraform returns an error on standing up the account. Despite the error, terraform builds the account.
if the apply failed but the account was built, an easy work-around is to import it. That way, the next apply won’t try to create it again
We thought about an import but the documentation states…
“Because of this, prior to running
terraform import it is necessary to write manually a
resource configuration block for the resource, to which the imported object will be mapped.”
Our account create code creates a couple of hundred resources so it would be too time consuming to write a config block for every resource. Unless the current code would would act as the the config block. Another consideration is that a lot of our modules depend on the the account ID which is returned by the account create module.
This means that you have to have the config written, at least with the required parameters, for a resource before importing it - but you already have that.
If you have a lot of resources defined, I would recommend that you split up into multiple configurations - sometimes referred to as “blast zones”, as they limit the damage that might happen when an apply operation fails to do what was intended. Just as an example, a split of an application into networking, database, application and frontend configurations means that I know that whatever happens when I’m working on the frontend won’t accidentally damage the persistent data. The
terraform_remote_state data source allows one configuration to consume another configuration’s output as input, so we don’t need to hardcode everything. Downside is of course that this is asynchronous as each configuration is updated separately.
Does this happen also when you use a completely new emailadress that is not already in AWS’ records?
If you need to have multiple accounts created and email messages received by the same inbox, I’ve been using the old ‘+’ trick to add unique identifiers to the adresses in the AWS account db, ie “firstname.lastname@example.org” and “email@example.com” both end up in the “aws” inbox at mymail.com.