NAT Instance maintenance - aws-lambda

Question

I have a Django app deployed on AWS Lambda through Zappa and my app needs to communicate with the public internet, so I need to use a NAT Instance. I am using a NAT instance because it's about 10x cheaper than a NAT Gateway using the free tier. The downside is that unlike NAT Gateway, a NAT Instance needs actual maintenance, and I am unsure what type of maintenance it needs. I want to learn about things I need to do to keep my server running well and healthy.
What are things I can do to make sure of that?
Here is my AWS Architecture:
All of the following is in my VPC. I have 1 subnet in ca-central-1a and 1 in ca-central-1b. In the route table, both subnets point to my NAT Instance. I have a 3rd subnet in ca-central-1b and in the route table it points to an internet gateway. My NAT Instance is in ca-central-1b.
My NAT Instance security group NATSG has HTTP and HTTPS inbounds from both of my subnets in ca-central-1a and ca-central-1b and outbound to 0.0.0.0/0. Should I make another NAT Instance in ca-central-1a and make it only inbound from the subnet in ca-central-1a i.e 1 NAT Instance for each subnet? Would that be healthier/safer?
Extra information:
I disabled Source/dest check. Was that a good idea?
For my AMI I chose a recent community AMI amzn-ami-vpc-nat and I created an Auto Scale Group which has my NAT instance. It only has 1 instance, is there any point of the Auto Scale Group if there's only 1 instance in it? I am not sure that I am using the Auto Scale Group right, I simply created it but haven't configured anything.

Answer 1

Maintenance for NAT instances is necessary for security updates, security groups and instance failures.
It's not necessary to place NAT instance in every subnet. You can connect multiple instance through single NAT instance. Also it is recommended to place NAT instance in public subnet.
source/destination check is enabled by default for each EC2 instance which shows that instance must be the source or destination of traffic which it send or receive. So source/destination check must be disabled for NAT instance as NAT instance is not source or destination to send or receive the traffic. It
just act as intermediate to send traffic to the private instances.
Below link gives the detailed description of Disabling Source/Destination Checks
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck
Setting up desired capacity to 1 will always keep your 1 NAT instance
up. But concern is when a NAT instance gets terminated, auto-scaling
group will launch the respective NAT instance which has
Source/destination 'enable' by default. We have to make it disable
manually, Also the entries which where made in route table by
selecting target as nat-instance-id will not get change and Route
Table will be pointing at the instance that was terminated. To get
SourceDestCheck attribute disabled for newly launch NAT instance you
could launch this from the User Data of the instance.Here is an example shell script.
EC2_INSTANCE_ID=`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id`
EC2_AVAIL_ZONE=`wget -q -O - http://169.254.169.254/latest/meta-data/placement/availability-zone`
EC2_REGION=`echo \$EC2_AVAIL_ZONE\ | sed -r 's/.{2}$//'`
echo "Region:" $EC2_REGION
aws ec2 modify-instance-attribute --instance-id $EC2_INSTANCE_ID --source-dest-check "{\"Value\": false}" --region $EC2_REGION
rc=$?; if [[ $rc != 0 ]]; then echo "Failure:" $rc; exit $rc; fi
echo "Success"

Answer 2

Sorry, #Rony Azrak for the delayed response. As your concern is to configure instance details after launch, we assume that you are considering about updating user-data script, the possible way to do so is to run the script through a shell. Just need to save the given script in .sh file say some a.sh and execute it through command as #sh a.sh.
But this changes will only be specific to instance, it will not reflect for next upcoming instance which may get launch through autoscaling if you are using it. For this purpose, you need to create a new launch configuration with required modification by adding the script in Advanced Details section, as existing launch configuration can't be edited. This ultimately leads to launching a new instance.
About Auto scaling, we would suggest you use auto scaling which will automate your task of launching an instance. It does not incur any extra charge you pay only for resources what you use.