Amazon introduces new service: Simple Notification Service

[ryandvm]

One of Amazon's SNS devs seems to be hanging around on reddit willing to answer questions about it.

http://www.reddit.com/r/programming/comments/bnn60/amazon_in...

[jasonlbaptiste]

The email notification part is what I find to be very interesting. I haven't looked at how in-depth you can configure things with deliverability / message customization, but I'd have to believe it's very robust. If it can do what I think it does, did it just make SendGrid dead in the water?

ie- 2 dollars per 100k messages via Amazon vs. 80 per month for 50k messages on sendgrid.

[terrellm]

Seeing as how EC2 IP addresses are being blocked by many spam blocking services*, I don't know that I'd want to depend on Amazon to ensure my emails are delivered. Sure I realize it's probably a different block of IPs, but I wonder how long before those get blocked too.

Source: https://community.engineyard.com/faqs/questions/ssmtp

[javery]

The only downside I see on the email part is that it required an opt-in from the subscriber side. I understand why it's there, but it could be confusing and limiting for people who want to use this as part of their SaaS app. You would have to select to be notified in the app and then also confirm it through email.

[shafqat]

That was my first thought, and we are happy SendGrid customers. Of course, SendGrid has analytics and lots of other features that help get emails delivered...But 2 dollars versus 80 is a huge difference.

[subbu]

no charges for the first 100,000 Notifications over HTTP and no charges for the first 1,000 Notifications over Email

Their free notification limit is quite generous.

[juvenn]

No, they'll bill you the data (e.g. messages you post to topics) transferred in from this June, then your first hits will not be free anymore. To quote from the page:

Data Transfer In will be $0.10 per GB after June 30, 2010.

[Mark_B]

Agreed! Strange though that Amazon doesn't heavily advertise how much of their developer-oriented services are actually free for people to 'kick the tires'.

[dandelany]

It's even better than that:

  First 100,000 Amazon SNS API Requests *per month* are free

[atlbeer]

That was my first thought... Just like crack, the first hit is free

[rgrieselhuber]

I can't tell you how long I've wanted something like this.

[PanMan]

Can you tell us why? What's that makes this so useful? I can't really come up with many good use-cases for it...

[blurry]

Future enhancements to Amazon SNS – such as notification delivery over SMS – will provide more protocol options and additional flexibility to mobile application developers.

Does anyone have an educated guess as to when the SMS transport option will be available? How long does it usually take Amazon to add a promised feature?

[d2viant]

I'd say a couple months at least. If you look at past and present future enhancements listed for their other services (such as RDS replication, Windows reserved pricing, etc.) they've all spent many months in development after the point at which they were mentioned to customers.

[nopal]

This will be great once they add SMS as a transport (listed under upcoming features).

[dryicerx]

In the mean time, you can ask your users the phone number+provider, and use the providers own email to SMS gateways. http://www.mutube.com/projects/open-email-to-sms/gateway-lis...

[Barnabas]

Or do it right now with Twilio: http://www.twilio.com/sms/

[mumrah]

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.

[charlesju]

From my understanding you still need to pool the SQS.

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.

[jbyers]

Read all the way to the bottom. A big caveat for now:

The following limitations are currently in place during the Amazon SNS beta: One hundred (100) topics per AWS account

[charlesju]

Almost every AWS service has limitations. EC2 gives you a limited amount of snapshots/ip addresses/instances per account, for instance.

The general policy for Amazon has been that as long as you email them telling them what you're doing with so much stuff they will give you the extra capacity you want.

[lux]

The requirement of publishing to a topic and not to individuals could be a big limitation too. I'd love to use a service like this to handle all the one-off emails (billing receipt, individual notifications) within my web apps that only send to one person, and I want to use a 3rd party so I'm not supporting the email delivery side of things (keeping us out of spam boxes), but none of the email services around seem to offer what's needed for this, including Amazon SNS...

From my experience, just setting up a secure email server with reverse DNS, SPF and DKIM, and having a privacy policy that you actually practice, is just not enough to ensure ongoing reliable delivery rates from your own server. Doing all that, we would still blast out email invites to ~50-100 people at a time, and one or two recipients would always find it in their spam box. Not good. With non-technical users, that became an annoying support problem and decreased the perception of our reliability/quality in their eyes too.

[rubyrescue]

this is interesting, but I wasn't happy with SQS so i'd be wary before we started using something like this over a custom notification system on top of RabbitMQ.

we used SQS for a while but kept having problems with polling - deleted messages would reappear with alarming regularity (which to be fair is documented by Amazon as a design tradeoff due to the distributed nature of the queue) - but it really caused a hassle to build a system that could handle these duplicate messages, especially when there was a lot of work to be done per message.

[javery]

I had the same problems with SQS and ended up using RabbitMQ and haven't had any problems. The main issue I saw with SQS was a couple seconds on unavailability every couple of days, enough that I had to start writing lots of client code to deal with it. RabbitMQ is rock solid.

[chasingsparks]

No more DKIM for me? No more burnt VPS IP's?

[mahmud]

Have you heard of Google Apps' Email? the free edition? for up to 100 domains (IIRC.)

[andr]

I would love to see support for HTTP long polling or web sockets, to allow this to be used for real time web apps.

[franck]

My thoughts exactly. This is the one feature that could be very big.

[lux]

Looks similar to messagepub.com and their message broadcasting, although with subscription verification, and groups, but minus twitter, google talk, AIM, etc. Will be interesting to do a comparison of similar services.

[agbell]

Amazon Simple Queue Service (SQS) and Amazon SNS are both messaging services within AWS, which provide different benefits for developers. Amazon SNS allows applications to send time-critical messages to multiple subscribers through a push mechanism, eliminating the need to periodically check or poll for updates. Amazon SQS is a message queue service used by distributed applications to exchange messages through a polling model, and can be used to decouple sending and receiving components.

[mark_l_watson]

Free for the first 100,000 Amazon SNS Requests per month - not bad. Also, $0.10 per gig transfered seems reasonable.

When Amazon released SQS I thought that everyone would use SQS, but in my limited experience with a small customer base, SQS is no where near as popular as using EC2s and S3. Interesting to see in a year how widely used SNS is.

[qjz]

I completely block the AWS address space on my servers because it's a major source of malicious probes and constantly siphons bandwidth at no apparent benefit to me. It looks like I'll have to consider less draconian measures now, if this is a source of useful messages and not merely a giant spam machine.

[ryandvm]

Unless you're just operating a personal network, that's a pretty blunt measure that you ought to revisit.

EC2 is certainly hosting legitimate business customers.

[dotBen]

I couldn't see anywhere that the emails would be 'white label' - thus appropriate to replace SendGrid.

It seems to me to be more geared up for machine-to-machine notificaiton, although granted that would make email a less efficient way of doing this instead of http

[franck]

I think they are white label since there's no mention of it.

Only the email confirmation is likely to officially come from Amazon.

[kylemathews]

What format are they using for the HTTP push notifications? It says in the FAQ that "Subscribers specify a URL as part of the subscription registration; notifications will be delivered through an HTTP POST to the specified URL."

Is this PubSubHubBub?

[juvenn]

Yeah, in its essence, the data flow is nearly the same as PuSH, that URL is named as callback in PuSH.

[tomstuart]

No, they just POST you the message (+ optional subject) as JSON.

[giardini]

How does SNS differ from RSS and Common Alerting Protocol (CAP):

http://en.wikipedia.org/wiki/Common_Alerting_Protocol

[thinkbohemian]

This is a great way to send emails, what about receiving them, is there any option with amazon other than getting an ec2 instance and putting a postfix server (or other MTA) on it?