Storing tfstate in between apply calls

Question

I've used terraform to create a configuration for my AWS VPC setup. The idea is to use terraform apply in each deployment as well as terraform destroy -target aws_nat_gateway.nat_gateway to remove the AWS NAT Gateway as it's only needed to properly deploy the application.

• How should I share/store my terraform.tfstate in between each deployments?
  • I've also considered using terraform show command but I don't know how am I suppose to load it back into terraform https://www.terraform.io/docs/language/state/index.html
• Should I also store terraform.tfstate.backup what it's responsibility?
• Are there other methods to make sure that existing VPC will be use? ( hardcode it's name like an SQL Table if exists )

Answer 1

The -target option for Terraform is not intended for use as part of any routine workflow, but rather as a way to work around bugs and limitations in exceptional circumstances where you might otherwise become blocked.

Thinking about your underlying problem rather than your proposed solution, it sounds like your system design requires that a NAT Gateway be present only while some other operation is happening, after which you want it to be destroyed.

Terraform is not an ideal tool for this scenario because it's typically for describing and managing long-lived infrastructure, which stays active indefinitely after you've initially created it. However, if you do wish to use Terraform to solve this problem then I would suggest decomposing the problem into smaller parts and then using automation to orchestrate running a few separate Terraform operations in the correct order.

Specifically, I'd write a Terraform configuration which describes only the "temporary" objects that you want to destroy immediately after the other action is taken (your NAT gateway, and anything else that's connected with it), and then another separate Terraform configuration which implies the actions that depend on that NAT gateway. For the sake of example, let's assume that these are in two sibling directories named transient and persistent, each of which is a separate Terraform configuration with its own configured backend.

Then you could automate this with a sequence like the following:

• terraform -chdir=transient init (prepare the "transient" working directory)
• terraform -chdir=transient apply (create the NAT gateway)
• terraform -chdir=persistent init (prepare the "persistent" working directory)
• terraform -chdir=persistent apply (plan and apply any necessary changes to the long-lived objects)
• terraform -chdir=transient destroy (destroy the NAT gateway)

This answer indirectly addresses one of your questions, which I'll now also answer more directly: the transient and persistent directories here will each have their own state, making it less likely that a mistake will cause someone to destroy long-lived objects when they were intending to destroy just the NAT gateway.