My Scenario: I have an SQS queue with an auto-scaling group of EC2 workers processing messages from the queue into a database in a different region.
Implied Networking Needs for EC2 Workers:
- Access Public Internet to interact with SQS
- Access Public Internet to interact with dB in different region
- Restrict unsolicited inbound traffic because these are not web servers
Networking Options (that I know of):
- Put EC2 Workers in a private subnet with no Elastic IP and allow them to communicate to the internet through a NAT running in a public subnet.
- Put EC2 Workers in a public subnet with public/ elastic? IP addresses. Put them in a restrictive Security Group which prohibits unexpected inbound traffic. Apply a restrictive ACL to the subnet to prohibit unexpected inbound traffic on the subnet level.
I have seen numerous recommendations for using the first approach with the NAT, including within AWS's own documentation. I have not seen any recommendations for the second approach.
NATs seem like an expensive option and can easily turn into a network bottle neck and are a single point of failure. Why is this option recommended so often? Are there disadvantages or deal breakers with the second approach that I'm not aware of?
This question is similar but not the same. I have also read this thread on stack overflow. I have also read the AWS VPC User Guide.