AWS NAT (Network Address Translation) Automated On-demand Destruct / Create

[csmcpherson]

Hi folks, 

Our company typically uses Databrick during a 12 hour block, however the AWS NAT for elastic compute is up 24 hours, and I'd rather not pay for those hours.

I gather AWS lambda and cloudwatch can be used to schedule / trigger NAT destruction and creation. 

1. Has anyone tried this with success, and can you provide guidance on best practice here?
2. Are there any important considerations to bear in mind (ie: will removal of NAT also destroy attached route tables / security groups / elastic IP allocation)?

Thank you.

[Kaniz_Fatma · Accepted solution]

Hi @csmcpherson, 

• Yes, you can indeed use AWS Lambda and CloudWatch to schedule and trigger NAT gateway destruction and creation. This approach allows you to save costs by only having the NAT gateway active during the hours you need it.
• Here are the general steps:
  • Create a Lambda function that interacts with the AWS SDK to manage the NAT gateway.
  • Set up a CloudWatch Events rule to trigger the Lambda function at the desired schedule (e.g., start at the beginning of your 12-hour block and stop at the end).
  • In the Lambda function, you can use the create_nat_gateway and delete_nat_gateway methods to create and destroy the NAT gateway.
• Keep in mind that you’ll need appropriate IAM permissions for the Lambda function to manage NAT gateways.
• When destroying a NAT gateway, it does not directly affect attached route tables, security groups, or elastic IP allocations. These resources remain intact.
• However, consider the following:
  • Route Tables: Ensure that your private subnets are correctly associated with the new NAT gateway after recreation.
  • Elastic IPs: If you release the elastic IP associated with the NAT gateway during destruction, it becomes available for other resources. You might want to reassign it to the new NAT gateway.
  • Security Groups: NAT gateways don’t have security groups directly associated with them, but they do have an implicit security group that allows outbound traffic. This behavior remains consistent during recreation.
  • Test thoroughly in a non-production environment before implementing this in your production setup.

Remember to adapt these steps to your specific environment and requirements.

If you encounter any issues during implementation, feel free to ask for further assistance! 😊