SQS VPC endpoints let your AWS resources talk to SQS queues without ever touching the public internet.
Here’s what that looks like in practice. Imagine a Lambda function in a private subnet that needs to send a message to an SQS queue. Normally, Lambda would need an internet gateway or NAT gateway to reach the SQS public endpoint. With a VPC endpoint, you create an Elastic Network Interface (ENI) in your VPC that acts as a gateway to SQS. Your Lambda function, when configured to use the endpoint, sends its SQS requests to the private IP address of that ENI. The endpoint then translates these requests and forwards them to the SQS service, all within the AWS network.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:my-private-queue"
}
]
}
This policy, attached to your SQS queue, grants sqs:SendMessage permission. Crucially, when combined with a VPC endpoint policy, you can restrict access only from specific VPCs or even specific endpoint ENIs. This is how you ensure only your private resources can interact with your SQS queue.
The core problem this solves is security and network complexity. By keeping traffic within your VPC and the AWS network, you reduce your attack surface. You also eliminate the need to manage NAT gateways or public IP addresses for your internal services that need to communicate with AWS services. It simplifies your network architecture and enhances your security posture.
Internally, a VPC endpoint for SQS is a "Gateway type" endpoint. This means AWS creates route table entries in your specified subnets. When traffic destined for the SQS service IP range is detected, the route table directs it to the endpoint ENI instead of the default internet gateway or NAT gateway. The endpoint ENI then handles the routing to the SQS service.
The key levers you control are:
- Endpoint Policy: This is attached to the VPC endpoint itself and controls who can access SQS through this specific endpoint. You can grant permissions to specific IAM roles or principals, and importantly, you can specify the
aws:SourceVpcoraws:SourceVpcecondition keys to restrict access to only your VPC or your endpoint. - Queue Policy: This is attached to the SQS queue and controls who can perform actions on the queue. You’ll typically combine this with the endpoint policy. For example, your queue policy might allow
sqs:SendMessagefrom any principal, but your endpoint policy would restrict that to only principals originating from your VPC via the endpoint. - Route Tables: You need to ensure the route tables associated with your subnets (where your resources reside) have a route that directs SQS traffic to the VPC endpoint. For gateway endpoints, this is automatically managed by AWS when you create the endpoint in those subnets.
Consider this: If you have an SQS queue and a VPC endpoint, but your Lambda function is in a subnet whose route table doesn’t have the SQS route pointing to the endpoint, it will still try to reach SQS over the internet (if it has internet access) or fail if it’s in a completely isolated subnet. The route table is the critical, often overlooked, piece.
The most surprising aspect for many is how the DNS resolution works. By default, when you create a VPC endpoint, AWS provides public DNS hostnames for SQS (e.g., sqs.us-east-1.amazonaws.com). However, when you are within the VPC that has the endpoint, and you try to resolve these hostnames, the DNS will resolve to the private IP addresses of the endpoint ENIs. This means your application code doesn’t need to change; it continues to use the public SQS hostnames, and the magic happens at the DNS and routing layer. You can also enable private DNS for the endpoint, which forces resolution to private IPs and disables access to the public SQS endpoints from within the VPC.
The next thing you’ll likely encounter is setting up interface endpoints for other services and understanding how their security groups and network ACLs interact with the endpoint ENIs.