Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been looking at adding NAT64 support to this and have been successful using the
nat_instance_user_data_post_install
variable. However, I noticed that when an instance is running in a dual stack network, DNS resolution is extremely slow (or possibly just API calls in general). For example, it takes 15m to provision an alternat instance + my post install script. I discovered it was the awscli calls that took forever.I found a way to increase the precedence of IPv4 addresses on the host using the getaddrinfo config. To test it, I wanted to make sure it was the first thing that happened in the user data, so I added a
nat_instance_user_data_pre_install
variable and set it to this:My instance setup time in a dual stack network went from ~15m to 2m.
Since I don't want to make any assumptions about people's networks (route table and subnet configurations) or whether they're using Jool vs Tayga (NAT64), I don't think it would make sense to add any of that stuff to this project, but a pre-install user data variable might?