I learned a long time ago that if you want an EC2 instance to be able to talk to AWS services like SQS, Kinesis and the like, the instance has to either have a public IP address or there needs to be something within the VPC doing NAT.
When I first heard about VPC Endpoints earlier this year it seemed like a game-changer — a way to access these services from instances that only had private IPs. But the fact that the only supported service is S3 seems really limiting. Every EC2 instance I currently manage has some other dependency on a non-S3 AWS resource that requires traffic to go out through a public IP.
I'm curious if there is any other benefit to using a VPC Endpoint for S3 anyway, with the understanding that the rest of the stack will still depend on public IPs and will for some time. Is there any measurable improvement in speed/throughput, or any other benefit that can outweigh the management overhead?
Best Answer
This is an old thread but they just released VPC endpoints for DynamoDB. I hope they add them for SQS. Right now since Lambda functions running in a VPC don't have internet access, they cannot access any public AWS services without setting up a NAT Gateway. So if you want your Lambda functions to access a resource in a VPC, RDS for example, and send something to SQS, SNS, SES, any other public AWS service without a VPC Endpoint or call another Lambda function, you can't.
If they added VPC endpoints for SQS you could access your VPC resources with a VPC lambda function, send results to a SQS queue, then have a public Lambda function watch and consume the queue messages, accessing any public AWS service (SNS, SES) as needed. Currently I am stuck 'watching' S3/DynamoDB since I don't want to incur the costs of a managed NAT Gateway.