Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-heal NAT Instances #96

Closed
osterman opened this issue Aug 26, 2020 · 2 comments
Closed

Auto-heal NAT Instances #96

osterman opened this issue Aug 26, 2020 · 2 comments
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@osterman
Copy link
Member

We should auto-heal our nat instances. Also, we should probably move NAT to it's own module and support gateways and instances interchangeably so we can re-use across our modules.

# Restart dead bastions and alert
resource "aws_cloudwatch_metric_alarm" "bastion" {
  alarm_name          = "${module.label.id}-status-check-failed"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = "5"
  metric_name         = "StatusCheckFailed_Instance"
  namespace           = "AWS/EC2"
  period              = "60"
  statistic           = "Maximum"
  threshold           = "1"

  dimensions {
    InstanceId = "${aws_instance.nat_instance.id}"
  }

  alarm_actions = [
    "arn:aws:swf:${var.aws_region}:${local.aws_account_id}:action/actions/AWS_EC2.InstanceId.Reboot/1.0",
  ]
}
@osterman osterman added the enhancement New feature or request label Aug 26, 2020
@Nuru
Copy link
Contributor

Nuru commented May 12, 2022

@osterman NAT Instances are deprecated and do not support NAT64. I am therefore not inclined to add additional support for them. Can we close this, or do you want to pursue it further?

@Nuru
Copy link
Contributor

Nuru commented May 13, 2022

The only reason to create NAT Instances instead of using NAT Gateways is to save money, currently on the order of $20/month. It is not worth the time and effort to further enhance this module's NAT Instance support beyond what is added in #159. Cloud Posse can create a separate NAT Instance module if there is demand for it, but it seems unlikely to me that the expense of supporting NAT Instances would not outweigh the cost savings they bring.

Our recommended cost-saving solution going forward is to use a single NAT Gateway rather than one per region. For a typical installation of 3 regions, that is approximately budget neutral (one NAT Gateway costs about the same as 3 t3.micro NAT instances), costing a total of about US $30/month.

For better NAT instance support, people can use an alternate module such as https://github.com/int128/terraform-aws-nat-instance (we have not vetted it, just noticed it) to create NAT instances and easily connect them to the private subnets.

module "dynamic_subnets" {
  source  = "cloudposse/dynamic-subnets/aws"
  version = "2.0.0"

  nat_gateway_enabled  = false
  nat_instance_enabled = false
  # etc . . .
}

resource "aws_route" "private" {
  count = length(module.dynamic_subnets.private_route_table_ids)

  route_table_id         = module.dynamic_subnets.private_route_table_ids[count.index]
  destination_cidr_block = "0.0.0.0/0"
  network_interface_id   = element(local.nat_instances.*.primary_network_interface_id, count.index)
}

@Nuru Nuru closed this as completed May 13, 2022
@Nuru Nuru added the wontfix This will not be worked on label May 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants