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.
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.
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.
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.
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.
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.
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, 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
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'.
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.
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.
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'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?
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)
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.
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.
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.
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.
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 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
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."
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?
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!)
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 :)
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.
http://www.reddit.com/r/programming/comments/bnn60/amazon_in...