The ability to subscribe to notifications using SQS is a very cool feature. Adding the ability to listen for things is really the linchpin of asynchronous architecture (in my mind). This sure beats polling a queue.
This new SNS service allows an application to push messages to various subscribers of a topic. Thus, if your SQS was subscribed to this topic, you could push a message to the SQS every time some action happens.
Then on the flip-side your SQS would still need to be processed by an EC2 server that polls the SQS.
From Amazon's FAQ:
“SQS” – Users can specify an SQS queue as the endpoint; Amazon SNS will enqueue a notification message to the specified queue (which subscribers can then process using SQS APIs such as ReceiveMessage, DeleteMessage, etc.)
The caveat here is of course if you have one of your end points be a HTTP/JSON API call and the EC2 server that is processing your SQS has a web server on it that will use the HTTP to trigger the polling process. But even in this situation, you're still doing a pull to dequeue the SQS.