7

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.

1
  • 2
    There is no charge for private IP addresses. Beyond the one public IP address you get per running instance it is $0.005/hour for both addresses not assigned to an instance and addresses assigned to an instance beyond the first.
    – Brian
    Oct 29, 2014 at 2:05

1 Answer 1

2

Many configurations need to share a single public IP. They need NAT. Your scenario's network traffic is all internally initiated. (SQS is polled.) With this type of traffic, there is no advantage to affording a NAT instance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .