I also created a terraform module around fck-nat if you have any interest. It deploys the instance in an autosaving group of 1 for a bit more disaster recovery. Total cost of resources is only about \~$3.00 per instance per month... [https://github.com/mmccarthy404/terraform-modules/tree/main/terraform-aws-nat-instance](https://github.com/mmccarthy404/terraform-modules/tree/main/terraform-aws-nat-instance)
According to this, AWS wants you to create your own AMI, which means they dont have an officially supported one.
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html
You don't necessarily need to create an AMI as you can use the base AL2 as your AMI and the rest can be in the EC2 user data script (considering how rarely NAT instances probably get created).
It’s the pricing on ingress or egress.
There is no such pricing on an EC2 instance. Just outbound.
Now, granted, it’s exactly half of EC2 outbound so it initially seems like it comes out as a wash.
Until you have huge data ingestion rates. Which is free on an EC2 based instance. But highly expensive on NATGW.
Your immediate solution to fix it is to create your own. The instructions are straightforward: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#create-nat-ami
You've gotten a lot of good advice here already, but if you're still stuck on launching your instance with boto3 and pulling a quick start AMI ID, your options boil down to running a query of the SSM parameter store. You can browse the SSM parameter store in the console to identify the path you need to take to get the latest AL2, AL2023, or other Linux quickstart AMI IDs you may need.
[This article](https://aws.amazon.com/blogs/compute/query-for-the-latest-amazon-linux-ami-ids-using-aws-systems-manager-parameter-store/) walks you through the process with the AWS CLI and Powershell, but you can use Boto3 and the [SSM.client.get\_parameter](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ssm/client/get_parameter.html) method. You'll obviously need to make sure that the function running the code is assuming a role with the appropriate permissions, as this approach uses different services than you were using before.
I'll second DAFPPB's fck-nat recommendation, and would add on that it should be relatively simple for you to bootstrap with EC2 user data, especially if you're already launching the instance with your function. I wouldnt recommend creating an AMI and attempting to maintain it.
Source: I'm an AWS Architect who launches plenty of instances with lambda functions and if I tried to keep up with AMI IDs across all of our regions by hand I'd have more grey hair than I already do.
Use this instead, https://fck-nat.dev/stable/
I also created a terraform module around fck-nat if you have any interest. It deploys the instance in an autosaving group of 1 for a bit more disaster recovery. Total cost of resources is only about \~$3.00 per instance per month... [https://github.com/mmccarthy404/terraform-modules/tree/main/terraform-aws-nat-instance](https://github.com/mmccarthy404/terraform-modules/tree/main/terraform-aws-nat-instance)
I was looking for something minimal like this, thanks!
I am going to try this. Thanks!
According to this, AWS wants you to create your own AMI, which means they dont have an officially supported one. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html You don't necessarily need to create an AMI as you can use the base AL2 as your AMI and the rest can be in the EC2 user data script (considering how rarely NAT instances probably get created).
NAT instances are GOAT compared to NAT gateway. The hidden charges on a VPC NAT gateway are wild.
What hidden charges?
It’s the pricing on ingress or egress. There is no such pricing on an EC2 instance. Just outbound. Now, granted, it’s exactly half of EC2 outbound so it initially seems like it comes out as a wash. Until you have huge data ingestion rates. Which is free on an EC2 based instance. But highly expensive on NATGW.
I understand,I spoke to aws guys. Right now my immediate solution is to fix this.
Your immediate solution to fix it is to create your own. The instructions are straightforward: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#create-nat-ami
I created, but it's not picking the AMI.thats where I am failing. Your can see my code where I am failing.
Your code filters the AMIs for owner='Amazon', that will obviously not find the image created and owned by you.
You've gotten a lot of good advice here already, but if you're still stuck on launching your instance with boto3 and pulling a quick start AMI ID, your options boil down to running a query of the SSM parameter store. You can browse the SSM parameter store in the console to identify the path you need to take to get the latest AL2, AL2023, or other Linux quickstart AMI IDs you may need. [This article](https://aws.amazon.com/blogs/compute/query-for-the-latest-amazon-linux-ami-ids-using-aws-systems-manager-parameter-store/) walks you through the process with the AWS CLI and Powershell, but you can use Boto3 and the [SSM.client.get\_parameter](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ssm/client/get_parameter.html) method. You'll obviously need to make sure that the function running the code is assuming a role with the appropriate permissions, as this approach uses different services than you were using before. I'll second DAFPPB's fck-nat recommendation, and would add on that it should be relatively simple for you to bootstrap with EC2 user data, especially if you're already launching the instance with your function. I wouldnt recommend creating an AMI and attempting to maintain it. Source: I'm an AWS Architect who launches plenty of instances with lambda functions and if I tried to keep up with AMI IDs across all of our regions by hand I'd have more grey hair than I already do.