The two common strategies for building HA NATs within AWS are:
- “Route Takeover” where an instance updates a route table to point to itself.
- “ENI Attaching” where an instance attaches an ENI to itself and the route tables are setup to point the default route to the ENI.
Both these methods involve an instance that updates the configuration of a resource (i.e. route table or ENI) either triggered by a “heartbeat script” or when created by an autoscale group.
This works fine with CloudFormation as an update to the stack doesn’t override these changes that have happened after that fact. This is not the case with Terraform.
Terraform will detect that the config for either resource has changed and will try and “fix the config” by removing any changes that happened outside of Terraform.
I get the philosophy here, but it’s preventing the deployment of HA NATs using the common strategies.
So, does anyone have any idea how to accomplish an HA NAT solution within the confines of how Terraform operates?
Thanks, Joe
Aucun commentaire:
Enregistrer un commentaire