4 ms·

- NAT Instances are placed in each Subnet for High Availability. This way, if one Availability Zone goes down and it happens to be where your NAT Instance is lo

- NAT Instances are placed in each Subnet for High Availability. This way, if one Availability Zone goes down and it happens to be where your NAT Instance is located, you don't lose connectivity. - Terraform vs. Ansible: /u/mitchellh (I think that's his HN name) started terraform and explained his "Terraform vs. Alternatives" in a Google Groups Post[1]. In addition to that post, Terraform also has nice support of multiple providers, so you can mix AWS, Azure, and others in one set of templates. In general, Terraform is doing a lot of cutting-edge thinking with orchestration tools and represents IMO a best-of-breed approach. That being said, there are a lot of bugs, especially around eventual consistency issues in AWS. They're getting better, and most of them are recoverable, though. [1] https://groups.google.com/d/msg/terraform-tool/6Fxnl_bejX4/0O-d17UwhHcJ https://groups.google.com/d/msg/terraform-tool/6Fxnl_bejX4/0...

toomuchtodo 10y ago
I believe you can use a Managed NAT Gateway now instead of NAT instances in each AZ for outbound VPC connectivity: https://aws.amazon.com/blogs/aws/new-managed-nat-network-address-translation-gateway-for-aws/ https://aws.amazon.com/blogs/aws/new-managed-nat-network-add... > In general, Terraform is doing a lot of cutting-edge thinking with orchestration tools and represents IMO a best-of-breed approach. Terraform isn't really doing anything that snazzy compared to Cloudformation [1] (an AWS tool) unless you're also orchestrating in concert with non-AWS services. [1] https://aws.amazon.com/cloudformation/details/ https://aws.amazon.com/cloudformation/details/
- cddotdotslash 10y ago
  I agree managed NAT is probably better (although can be more costly), but you still need a managed NAT Gateway in each AZ.
  - conorgil145 10y ago
    Absolutely correct. We are using NAT Gateways in our architecture, and I love not having to manage it all myself, but it is definitely a tradeoff in costs. From the AWS documentation [1]: "Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone. You have a limit on the number of NAT gateways you can create in an Availability Zone. For more information, see Amazon VPC Limits. Note If you have resources in multiple Availability Zones and they share one NAT gateway, in the event that the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose Internet access. To create an Availability Zone-independent architecture, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone." [1]: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-n...
- joshpadnick 10y ago
  > Terraform isn't really doing anything that snazzy compared to Cloudformation I'd disagree with that. Just take a look at the Terraform Changelog[1] for some of the latest & greatest. For example, the concept of "Data sources" is pretty cool. Basically, you can reference pre-existing data, potentially do rich queries against it, and get a read-only value back. For example, you can use a Data source to find the latest AMI for a given search string.[2] CloudFormation has a concept of Custom Resources[3] which could achieve similar functionality, but not without a lot of hassle. Terraform has also been building up a rich language of interpolation functions [4] that can be used for string replacement, hash generation, and even arithmetic. There's a lot more, too. I think it goes well beyond "cloud-agnostic." [1] https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md https://github.com/hashicorp/terraform/blob/master/CHANGELOG... [2] https://github.com/hashicorp/terraform/blob/master/website/source/docs/configuration/data-sources.html.md https://github.com/hashicorp/terraform/blob/master/website/s... [3] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid... [4] https://www.terraform.io/docs/configuration/interpolation.html https://www.terraform.io/docs/configuration/interpolation.ht...
  - toomuchtodo 10y ago
    I don't disagree it has some "cool" features, but we've been bitten pretty hard in production when Terraform takes action that wasn't expected (and fell outside of what the plan called for before performing the apply). Doing devops, I prefer boring and reliable over cool.
    - joshpadnick 10y ago
      Definitely hear you on that, and we've taken steps to mitigate Terraform's "surface area" after we encountered some problematic use cases. This excellent article [1] does a nice job of talking about why it's important to keep your tfstate files small and isolated. Since we started doing that, working with Terraform has been much nicer (and safer!). [1] https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-tfstate-file-per-env/ https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-wan...

toomuchtodo 10y ago

I believe you can use a Managed NAT Gateway now instead of NAT instances in each AZ for outbound VPC connectivity: https://aws.amazon.com/blogs/aws/new-managed-nat-network-address-translation-gateway-for-aws/ https://aws.amazon.com/blogs/aws/new-managed-nat-network-add... > In general, Terraform is doing a lot of cutting-edge thinking with orchestration tools and represents IMO a best-of-breed approach. Terraform isn't really doing anything that snazzy compared to Cloudformation [1] (an AWS tool) unless you're also orchestrating in concert with non-AWS services. [1] https://aws.amazon.com/cloudformation/details/ https://aws.amazon.com/cloudformation/details/

cddotdotslash 10y ago
I agree managed NAT is probably better (although can be more costly), but you still need a managed NAT Gateway in each AZ.
- conorgil145 10y ago
  Absolutely correct. We are using NAT Gateways in our architecture, and I love not having to manage it all myself, but it is definitely a tradeoff in costs. From the AWS documentation [1]: "Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone. You have a limit on the number of NAT gateways you can create in an Availability Zone. For more information, see Amazon VPC Limits. Note If you have resources in multiple Availability Zones and they share one NAT gateway, in the event that the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose Internet access. To create an Availability Zone-independent architecture, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone." [1]: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-n...
joshpadnick 10y ago
> Terraform isn't really doing anything that snazzy compared to Cloudformation I'd disagree with that. Just take a look at the Terraform Changelog[1] for some of the latest & greatest. For example, the concept of "Data sources" is pretty cool. Basically, you can reference pre-existing data, potentially do rich queries against it, and get a read-only value back. For example, you can use a Data source to find the latest AMI for a given search string.[2] CloudFormation has a concept of Custom Resources[3] which could achieve similar functionality, but not without a lot of hassle. Terraform has also been building up a rich language of interpolation functions [4] that can be used for string replacement, hash generation, and even arithmetic. There's a lot more, too. I think it goes well beyond "cloud-agnostic." [1] https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md https://github.com/hashicorp/terraform/blob/master/CHANGELOG... [2] https://github.com/hashicorp/terraform/blob/master/website/source/docs/configuration/data-sources.html.md https://github.com/hashicorp/terraform/blob/master/website/s... [3] http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid... [4] https://www.terraform.io/docs/configuration/interpolation.html https://www.terraform.io/docs/configuration/interpolation.ht...
- toomuchtodo 10y ago
  I don't disagree it has some "cool" features, but we've been bitten pretty hard in production when Terraform takes action that wasn't expected (and fell outside of what the plan called for before performing the apply). Doing devops, I prefer boring and reliable over cool.
  - joshpadnick 10y ago
    Definitely hear you on that, and we've taken steps to mitigate Terraform's "surface area" after we encountered some problematic use cases. This excellent article [1] does a nice job of talking about why it's important to keep your tfstate files small and isolated. Since we started doing that, working with Terraform has been much nicer (and safer!). [1] https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-tfstate-file-per-env/ https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-wan...