Amazon introduces new service: Simple Notification Service | Hacker News Reader

Amazon introduces new service: Simple Notification Service

aws.amazon.com

199 pointsryandvm80 comments

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...

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.

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.

i read that, but my guess is this: the "opt-in" part is taken care of when you do a normal confirm this registration email. if this is a huge issue for devs, Amazon will just deal with it.

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

Why couldn't SendGrid get blocked?

They could, but I assume SendGrid has more checks in place to prevent their users from sending unwanted emails. That way SendGrid has little risk of getting blacklisted, whereas a presumably uncontrolled service like Amazon's would.

They assign IP addresses to each of their clients. If a client sends spam, only that IP gets blocked.

You'd hope.

I'm aware of AWS firewall blocks at various sites.

Have a look around at some of the forums for web masters, and you'll find wholesale blacklisting of these server farms is regularly discussed. And implemented.

The presumption being that outbound connects from these server farms are usually something where the VPS has vastly more bandwidth, or bugs, or breaches; where the attackers and the spammers and the scrapers have quickly adopted or targeted these server farms just because of their capabilities.

And yes, there are well-intentioned folks using AWS that are getting painted with this same brush.

Let's say SendGrid did get blocked, despite their work to make sure they don't (they have more of vested interest than Amazon do).

If it was costing them serious business, presumably they would change their IPs, etc. Where as Amazon are unlikely to because sending email isn't their core business.

Hard to say. Amazon takes all their AWS products pretty seriously. I am sure they have thought through email deliverability. I wouldn't discount their solution just because their EC2 IPs have been blocked in the past for mass email.

From what I understand this service is completely opt-in via the customers email address. I'm not sure you could actually send unsolicited messages.

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.

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.

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

I think this technique is very effective at getting the "Hacker News" types to experiment with their service. I know I wouldn't have played with App Engine if Google didn't have a free offering at the low volume end.

It's no-minimum pricing that allows me to play without thinking too much about it first. Spending $2.63 for an afternoon of fiddling is close enough to free for my needs. I do agree that Google's AppEngine has benefited significantly by giving away enough power to run simple sites.

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'.

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.

Seems generous to me even with that info. I don't know the packet size/charge per notification but I have trouble imagining the scenario in which one goes from 0 notifications (today), to using up 100,000 free notifications, and then to using up so many notifications you care/notice $0.10 per GB - all by June/July

It's even better than that:

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

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

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...

Well for one, I think you could effectively run a PubSubHubbub server or subscriber node on top of this.

I had to google for "PubSubHubbub" because it sounded too ridiculous to exist in actual, physical reality. But it looks like a pretty cool project.

I use multiple cloud / VPS accounts and it's a much cleaner means for sending messages between data centers than polling.

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?

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.

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

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...

The email to SMS gateways are much slower in my experience than sending an actual SMS message through a quality service like OpenMarket.

Unfortunately with that system when people change carriers they have to remember to notify you. (full disclosure: I work for Twilio but I have been trying different SMS techniques for years so this comment stems from that experience)

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

At 3 cents a message, my freemium service would go bankrupt fast. Twilio has way overestimated the value they provide. My guess is that AWS will be much cheaper, like 100x - 1000x cheaper.

I thought the SMS problem was that the phone carriers apply higher fees to them?

Perhaps Twilio does pay the carriers, but I send hundreds of text messages a day and pay nothing because I send it through their email to SMS gateway.

I'm a long time HN user that just started at Twilio so I'd love to talk to you about your app. Can you email me at jsheehan@twilio.com if you want to talk more?

Blame the carriers, not Twilio.

Just like SendGrid might be in trouble, Twilio must also be wondering what the future will hold.

Would love to see someone from SendGrid and Twilio come here to explain the main differences and the cost/benefit of the two services.

I just started at Twilio two days ago so I don't have an answer for that but I'll see if I can track someone down that does.

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.

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.

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

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.

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.

I see mention of SendGrid, which looks like it might do this. Didn't see that in my prior research. Have I found a solution here folks?

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.

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.

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

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

I use it for my email. However, if I believe they take issue with sending lots of automated emails (e.g. signup verifications).

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

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

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.

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.

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.

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.

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.

I'm just blocking originating connections from AWS on select servers. It's riskier in theory than in practice, as even the nonmalicious connections don't add much value. But you're right, I'm revisiting and will probably scale it back to just block web crawling, as no human activity seems to originate from that space.

I am using EC2 to proxy web surfing for iPhone users, so I hope not too many website are blocking all traffic from AWS.

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

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

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

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?

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

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

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

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

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?

i would love to see this hook into apple's push notification service:

http://developer.apple.com/iphone/library/documentation/Netw...

too bad they don't use webhooks :(

Urban Airship has a similar service (even priced similarly): http://urbanairship.com/ Their focus is specifically mobile apps, & they have nice sample code for iPhone/Android/Blackberry. Gets spendy faster than Amazon, but I've used it for personal stuff and it's really easy.

Ex.: I do a lot of database work recently, so when I kick off a 90min query, at the end I ping them with some JSON and my phone meows. (Meow! Stop drinking! Your query is done!)

I do this with notifo right now. It's quite useful. I've gotten Boxcar and messagepub to do the same thing for me, but I like notifo's UI.

This is exactly why I built Notifo, to solve this problem... especially for webapps/services that don't have native mobile apps. I am going to be playing with SNS very soon and hopefully get some example code up to show SNS/Notifo playing nicely together :)

Was I the only one who mistook this for a framework to allow for text-message notifications?

google wave (vision), anyone? http://www.jasonkolb.com/weblog/2009/09/why-google-wave-is-t...

This is great. Amazon is really putting out some great feature.

It seems each user can only create 25 topics. That sucks.

Perhaps Amazon SNS isn't the best name.

This looks like a huge clone of http://hook.io/. Granted, Amazon's service appears to be much farther along, and is likely going to support higher loads, but the concepts are the same.

That's like saying EC2 is a copy of Slicehost.

There's a limited set of ideas that are ready for development at the cusp of CS at a particular point in time.

hook.io is FOSS and Saas

SNS is just Saas

Reply on news.ycombinator.com