Create an interface VPC endpoint for Amazon SQS, enable private DNS, and attach an endpoint policy that names the principal, actions and queues allowed. Applications in the VPC then reach SQS without an internet gateway, NAT instance or VPN connection. You can also write queue policies that deny requests not arriving through the endpoint.
What the endpoint does
AWS describes a VPC endpoint for SQS as a logical entity within your VPC that allows connectivity only to SQS. The VPC routes requests to SQS and responses back. You use the connection to send messages to queues without crossing the public internet, and the endpoint gives reliable, scalable connectivity without an internet gateway, NAT instance or VPN connection.
Two details from the documentation matter in practice. First, you can use a VPC only with HTTPS SQS endpoints. Second, you must enable private DNS and use endpoints in the format sqs.region.amazonaws.com, or sqs.region.api.aws for dual-stack. Private DNS does not support the legacy endpoints such as queue.amazonaws.com, so clients that still use those names will not use your endpoint.
An endpoint policy
The endpoint policy states the principal, the actions and the resources. AWS's example allows one IAM user to send messages to one queue. The documentation says the following are then denied: other SQS API actions such as CreateQueue and DeleteQueue, other users and rules that try to use the endpoint, and that user sending to a different queue. The note adds that the user can still use other SQS actions from outside the endpoint if their other permissions allow it, so the endpoint policy does not replace the IAM and queue policies.
Steps
- Create the interface endpoint for SQS in each VPC that runs producers or consumers.
- Enable private DNS and confirm the clients use the regional endpoint name.
- Write the endpoint policy with named principals and queues. Avoid a wildcard if you can.
- Update the queue's access policy so that requests must come through the endpoint. AWS's policy examples include one titled "Deny access if it isn't from a VPC endpoint."
- Test from inside the VPC that producers and consumers still work.
- Test from outside it that the denied path fails, using credentials that would otherwise be allowed.
- Add the endpoint, policy and queue policy to your infrastructure code so the setup is repeatable and reviewable.
What the endpoint does not do
It controls the network path, not the content. A permitted producer can still send a malicious or malformed message, and a permitted consumer can still mishandle it. It also does not encrypt message bodies at rest. For that, see SQS SSE-SQS or SSE-KMS: which encryption to pick. It does not fix an over-broad principal either, which is why the Principal star guide belongs alongside it.
Common problems
- A Lambda function or container outside the VPC cannot reach the queue once you deny non-endpoint traffic. List every caller, including build jobs and data pipelines, before you add the deny rule.
- Clients configured with the legacy endpoint name bypass private DNS.
- FIPS requirements: AWS documents FIPS endpoints through PrivateLink using the sqs-fips endpoint service. Check this if you have such a requirement.
Safeguard's policies and gates can review infrastructure code changes like these before they merge, and the free scan can show your dependency inventory.
Quick check
Do I need a NAT gateway for my private subnets to reach SQS?
Not if you use an interface endpoint. AWS says the endpoint connects without an internet gateway, NAT instance or VPN connection.
Does the endpoint policy block access from outside the VPC?
Not by itself. AWS notes a user can still use SQS from outside the endpoint if other permissions allow it. Add a queue policy that denies requests not from the endpoint.
Sources
Last reviewed: 19 October 2026.
