Introducing Amazon Simple Email Service | Hacker News Reader

Introducing Amazon Simple Email Service

aws.amazon.com

438 pointsYrlec168 comments

I love what Amazon is doing with AWS, and I like this new service a lot. Plus I'm a happy customer.

But damn this is all getting very complicated. First they turn off email, so you have to find a provider, then they turn it back on, but you have to pay them. Looking at my AWS console, I've got 8 or 9 tabs on there -- each representing a little piece of what I might want in an app. Each has it's own help section with bunches of docs to read to get up to speed. Each has it's own forum category. Each has a usage policy.

Don't get me wrong -- it's all good stuff. But good luck trying to guestimate what kinds of prices you'll be paying. You're paying for data transfer in and out of the cloud, you're paying for disk storage, you're paying for a database, you're paying for basic email services, etc.

So I'm kind of stuck looking at the monthly bill and saying "Does this look about right?" instead of having some firm idea of what's going on without having to use a spreadsheet and 3 whiteboards. That's no good. It's probably completely acceptable for BigCorp, who has a guy dedicated to figuring all of this out and managing it, but I'm busy and pressed for time all I want is the big red button to push -- and a known price for pushing it.

I love what they're doing. Just wish they'd put a little more "simple" back into it, especially in terms of pricing and bundling.

Seems like a white labeling opportunity. Though I am not sure if their TOS allows it.

Could anyone explain the usage of 'white label' here? The Wikipedia entry (+) doesn't help this foreign speaker.

(+) http://en.wikipedia.org/wiki/White-label_product

Resell services under another name, maybe in another package. In this particular case, with a fixed price :)

"White label" in this context would basically be a middleman. Customer pays the white label for the AWS services and the white label pays AWS.

The white label would obviously have to offer something of value and in this discussion, that value would be predictable pricing and maybe simplification of the services.

Thank you and jrnkntl (edit: and alttab) for explaining it.

Actually white label doesn't quite describe it correctly, as white label is normally just that - a relabelling.

Typically, in addition to releasing it as a different brand for the same services, pricing might be altered, customer service would be seperate, different marketing, and so on. It's not a term designed for creating a new service that happens to use AWS underneath it.

(Depending on how much the "simplification of the services" changes the AWS offering, maybe I'm being pedantic, but maybe not. Dropbox, for example, is not a white label solution, it's a completely seperate example, even if it 100% uses AWS services.)

I think white label here means manage and package aws services under one bill

Edit, which could also mean a custom interface

Sendgrid is essentially an Amazon white label e-mail service now.

See: Heroku

AWS is awesome for exactly that reason, one can build a more integrated package on top of the individual parts and sell it.

Or dropbox...

You think that's complicated? Boy, back in my day, we didn't have no fancy "management console" or "tabs". Why, you had to play with your AWS services by hand! And you liked it.

Wanted: A webapp/dashboard that tracks money you have spent acorss Amazon services.

http://aws-portal.amazon.com/gp/aws/developer/account/index....

There is actually a company that does this. But since Amazon doesn't do OAuth, they require you to give them your amazon login and password. They download your account usage logs from amazon and put a GUI over it. The password requirement was a showstopper for me so I didn't even try the co. The graphs sure looked pretty. :)

Sorry, the name of the company escapes me ATM.

ylastic.com

Which was still infinitely better than racking your own servers and then, later, driving to the colo at 4:30 am because of yet another contingency you failed to anticipate in your HA planning. One of the earlier contingencies was that the colo's "remote hands" service was actually staffed by bonobos.

Seriously, the lack of a flat fee model is the main thing that has kept me away from AWS.

That's the point, though: usage driven fees. It's absolutely not the most economical offering, but the freedom and ability to either quadruple your infrastructure or shut it down entirely, no strings attached, in an instant is what you're paying for.

With most of dedicated server providers now, you can get any server with a 1 month contract, no strings attached, for a fraction of the price of an equivalent ec2 instance, and good IO as a bonus. And good providers usually delivers within 24h.

I love aws services and use them myself, but for ec2, but I doubt most users have such volatile needs. The main advantage I see, for aws users (non ec2) is to have everything in the same place.

I would love it if you could provide a link to your cheaper for more service providers. I've not found anything comparable for less $. Also, if you're comparing lock-in prices, compare them against the EC2 reserved instance prices.

How about http://www.hetzner.de/en/hosting/produktmatrix/rootserver-pr...

and

http://www.hetzner.de/en/hosting/produktmatrix/rootserver-pr...

been with them for 3+ years and never had a problem

They look great. Too bad they're in Germany :(

serverbeach has dual quad-core servers with 6-48 gigs of RAM for relatively reasonable prices, month to month.

I used to use serverbeach. They are definitely not cheaper if you compare RAM to RAM (just under 2x the cost of EC2 reserved), but of course they're dedicated not VPS, which is a better offering... not sure how much more their cheapest dedicated boxes are worth in comparison to an ec2 small instance though.

http://www.gandi.net/hosting

Interesting pricing breakdown (reminds me of Heroku), however they seem to be more expensive than Linode and definitely more than EC2.

They're cheaper than both for bandwidth which is what I care about most.

Yeah another shout for hetzner http://www.hetzner.de/en/, their eq line is pretty good value for money http://www.hetzner.de/en/hosting/produktmatrix/rootserver-pr...

How about research uses? That kind of computing power is almost entirely un-buyable at the short terms many research needs have. You buy a month, or you buy nothing. EC2: you buy a minute, if that's all you need.

> With most of dedicated server providers now, you can get any server with a 1 month contract

Still not really the point. You're going to have to buy enough servers in advance to handle your peak load every month. And then you're going to have to forecast ahead at the end of the month and cancel all the ones you don't need. It might be theoretically possible but in practice it is ridiculous. EC2 brings the contract interval to 1 hour and lets you control it with API calls.

http://newservers.com/ does hourly-billed, API provisioned, dedicated servers.

Many companies will resell space to you on AWS with a flat fee model. Many hosts now are simply AWS front-ends.

In my limited experience, the actual costs have been small enough that I regret even spending time on a detailed spreadsheet based cost model to predict costs.

At some point, that will change. At that point I'll have a very clear basis for calculating ROI on migrating to different infrastructure.

On the other hand, because of the utility-based charges, you can run tests for a week or two if you'd like.

Also, it sounds like what you're looking for is basically a calculator on top of the service -- are there really no decent calculators online?

I think Elastic Beanstalk is intended to reduce much of this complexity, as well. Want your app to just scale? clicks on EBeanstalk.

Sendgrid & other such senders will be shaking in their shoes now. Personally, as soon as I have more time, I'll switch to the amazon service. Also, any new app I make will use Amazons service by default.

Sending email out is quite important for growth, and such services really help businesses.

What impresses me about amazon is that they are not looking at what the competition is charging or trying to charge high based off the fact that there are not too many such services, but are simply providing the service at a reasonable price.

I think they aligned their prices with Google App Engine (they charge the same $0.1 per 1000).

Why are you going to switch from the other providers to Amazon? Because of price?

The thing is, Sendgrid et al will continue to innovate in terms of feature set, and AWS never will. And that's a good thing: They focus on the absolute core of a product need - and let providers like heroku or dropbox grow like a vine on top of them, providing things people want.

> Sendgrid et al will continue to innovate in terms of feature set, and AWS never will

Seems to me that Amazon has been quite busy innovating and expanding their feature set.

You're right, I misspoke when I said "innovate" - what I meant was, Amazon's goal is to create reliable base-level services for the developers of the world. Whereas a Sendgrid might provide unsubscribe management and fancy graphing, I don't see Amazon adding on additional services like this.

then they'd be moving into MailChimp's turf! I'd say they're in a pretty tight spot...

They already added fancy graphing to EC2, EBS and RDS just recently. What used to be CloudWatch services became free and integrated into the dashboard of those other services. Elastic Beanstalk is also a layer above their base-level services. Seems like Amazon is willing to move up the chain and will continue to in the future.

I think there's only one appropriate response when Amazon comes stumbling into your market: http://blog.easydns.org/2011/01/18/easyroute53-nameserver-in...

I think this must have always been a concern for companies like Sendgrid. As someone who operates a service to allow incoming email (CloudMailin) there's nothing more worrying than the big boys coming along an sweeping you up. However, so long as you continue to add value people will choose your product over the competition. Moves like this can ultimately lead to a far better product in the long run.

Having tried the service it's currently clunky and command line based too! I wouldn't actually call these comparable products. SES seems more like it replaces transactional emails that users might have previously event sent without a lot of a anti-spam measures. The value that companies like Sendgrid/Mailchimp/Postmark add outweighs the price for me and, at least, in the short term I won't be moving anywhere.

Sendgrid is half as expensive once you get beyond sending a handful of emails. $.005 vs $.01

I am a sendgrid customer, and unless Amazon is cheaper and can solve the deliverability issues, there is no way I'm switching.

Amazon is $0.10 per 1 thousand emails.

Sendgrid is $0.00045 at the highest tier which is $0.45 for 1 thousand.

That means Amazon is much cheaper even at Sendgrid's highest tier, further, it's much cheaper at the lowest tiers as well.

Wow, I'm an idiot and you might have just saved me a bunch of money, so thank you!

Why? We use Sendgrid where I work and they're great. Probably quite a bit more expensive though. We pay over $100 a month just to send email.

Umm .. that's why!

I wonder how they will respond if an account gets over the allowed threshold of spam complaints. I could see them responding either by:

a) Cutting off the customer's use of Simple Email Service; or

b) (Much much worse) cutting off the customer's AWS account, including EC2 and so on.

I'm guessing a), but it would be nice to have assurances against b). Otherwise a false positive on the "they're using SES to spam" detection system could be catastrophic.

The SES docs just point to the standard customer agreement - http://aws.amazon.com/agreement/ - which doesn't appear to make any specific mention of SES terms and conditions.

How would legitimate use be falsely flagged as spam in large numbers? Other than a malicious conspiracy of some sort, I don't understand why a disproportionate number of e-mail recipients would target legitimate mail as spam. Am I missing something?

Well, illegitimate use has to be handled appropriately as well, or we're in a "This is why we can't have nice things" scenario.

All sorts of things can lead people to erroneously assume that an email is spam (and mark it as such).

For example, if your app sends out an automated email that isn't clear about what site/service it relates to, a proportion of recipients are likely to mark it as spam without reading it and figuring out who its from. Few people have time to read email that looks to them like spam.

Or, if your company or service emails its list of subscribers for the first time in months, quite likely half the list will have forgotten who you are and the fact that they opted in to your list in the first place. And a disproportionate number of them will mark your email as spam.

Or if people sign up for MyBrandedWebsite.com, but then receive an email from Software Company X (the company behind MyBrandedWebsite.com), people won't recognize the link, and a proportion will mark the email as spam. It's a rookie mistake on the part of Software Company X, but it happens all the time.

Ultimately, minimizing spam reports requires a lot more than double opt in and an unsubscribe link.

Amazon will be keen to minimize spam reports for emails sent through their system, because they'll need to ensure that their deliverability rates stay high. So they'll need good automated systems to detect spammers. But email/spam detection is an inherently fuzzy business, and false positives are inevitable. If a false positive could bring down an entire service hosted on AWS, even if just for a few hours, then using SES starts to look pretty risky.

People sign up. People get tired of your email. Clicking spam is easier than clicking unsubscribe (which people are also taught not to click on). Both AOL and Yahoo have been pretty aggressive about banning mail servers that send too much "spam", which in several cases was a legitimate mailing list people had to ask to subscribe to.

I've seen some aggressive stuff out of Excite, as well (although I only know a few people who use them).

One other reason someone might hit "Report Spam" rather than unsubscribe: your unsubscribe page requires an account login (rather than unique hash) to unsub. If I can't remember that login, and I'm exasperated by the company already, I'll hit the Report Spam button just b/c it's so much easier.

Email unsubscribes that are behind login screens are the devil.

For years, people have been told 'don't click on "Unsubscribe" in spam, it just tells people that your e-mail address really exists'.

Except that people can't tell the difference between 'e-mail I don't want and never asked for' and 'e-mail I signed up for but don't remember', so they click the 'spam' button automatically. For a lot of people, the 'spam' button is actually the 'I don't want to get these e-mails anymore' button.

This is why companies like AOL, etc. have feedback loops. You register yourself with them, and you set your system up to handle spam complaints. When a user complains about a legitimate message, you just remove them from your list. If you don't have those feedback loops set up, then AOL assumes you're being a dick (and/or the spam complaints go to the IP address owners, who've registered themselves already).

We have had our entire account at threat of termination because of spam complaints. Here is the scenario: We aim to be for designers what heroku is for developers, so we resell amazon's service. A designer's client (Small business, medical industry) was mailing SPAM emails from yet another party's shady service, but linking to the AWS-hosted website.

Amazon sent a semi-threatening email directly to me, along with the email in question so I could deal with the culprit. It happened twice. The second time us, and the small business client needed to part ways so that I could keep ensuring AWS that we were being good stewards of their IP addresses.

You get a daily quota of 2000 messages if you're an EC2 customer. That's pretty competitive, and nicely within the limit of what I'm sending at this stage of my startup. Sold, well played once again Amazon.

I can send up to 2K messages a day with a premiere Google Apps account.

Which you've paid for separately. This is inclusive if you've got an EC2 server.

That may be true, but from what I remember, the transition past 2000 was very difficult with Google Apps. In the end you'll have to go with a email provider like SES (or the now troubled PostmarkApp).

Wait... troubled? I use Postmark...

Which is now almost 15 times as expensive as Amazon SES. (Almost, because Amazon also charges a small data fee.)

Here's my blog post:

http://aws.typepad.com/aws/2011/01/introducing-the-amazon-si...

If you like to solve puzzles, be sure to read the PS!

Jeff, join the HN phonetool page :-)

Will do!

You forgot to mention this at your PHP Meetup talk last night. I'm enjoying your book by the way. Thanks.

Hmm, you made me hungry.

I don't have time to solve it, but translated from binary to text is .zncf anug erggro fv abpno

Anyone want to take up the mantle? :D

The bitstream converted to their ASCII value is ".zncf anug erggro fv abpno". When reversed and ROT-13ed, it is:

"Bacon is better than spam."

Indeed it is!

Jeff, are there any plans to support mailbox provisioning?

At the moment I'm using Rackspace's REST API to create a mailbox for our new customers. I like their API, but I don't like the fact that we have to communicate with their IMAP and SMTP servers to receive and send email. It forces us to write a lot of bug-prone email handling code.

Could Amazon help in this kind of a scenario?

It seems they implemented a gradual increase of daily quota to protect themselves against spammer abuse.

Here's the link to the document describing the system:

http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/...

And also, after you sign up for SES, you can't actually use it to send out emails to your customers until they grant you 'production' access. This process seems to be done manually as they say it can take up to 24 hours after an initial request, and from the sounds of it, someone contacts you personally to confirm your email usage.

Just an update, I requested SES production access 4 hours ago and just received notification that I was approved.

Maybe they ramped up support to handle the launch day? Or maybe it's because I've been an AWS user for years, or maybe because I've been using $1000/m worth of AWS services for a month, and the SES account was for the same website hosted on my AWS.

Update: switched all my web servers to use SES via Postfix. So far so good! Setting it up over postfix took ~10 minutes including installing the perl libs needed

I wonder who's going to be the first to announce a SMTP proxy for this?

More seriously:

While I can kind of understand that Amazon has their API and probably wants this to work similarly, but there is already a wide-spread protocol for sending out email (SMTP) and I just can't understand why they can't provide an endpoint for that.

Many applications which I really see making use of this already have built-in SMTP support (and are using that today), so why force developers to work with another, completely different API to send email over Amazon?

If they use SMTP, they run the risk of a compromised server sending spam through them. With the API, it makes it a bit more difficult for a compromised machine to start spamming, unless it already has API keys for this service.

Nothing prevents them from requiring SMTP-Auth for authentication to make sure that the sending is coupled to a specific account.

If we are talking compromised machines, then the key would be compromised as well at which point a spammer can use that key to send spam regardless of protocol.

I'm not saying to use smtp auth with your amazon username and password, but with some token derived from the API key, but just SMTP.

Except they already have auth setup for all their other webservices. Why not make email yet another service and the auth infrastructure is already there.

Makes sense to me. Those gradual rate increases show they're pretty wary of the spammer threat.

Unless the compromised server already has sendmail or postfix configured to use Amazon's perl script as a transport (according to the directions in Amazon's own help files). In that case, the attacker doesn't have to even bother looking around for the API keys --- everything's already set up.

purely security by proprietary obfuscation? clueless.

Check this out: http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/...

You can configure SES to work with Postfix or Sendmail. It's at least close to what you're asking about.

Their solution involves hooking a perl script into mail delivery for sendmail and postfix.

Now, I have nothing against that method in general, but if you need to send so many emails that it's useful to use the Amazon service, then forking, starting up perl and then running that script for every email you are sending might not be a viable option performance-wise.

On the other hand: If you are using amazon's service for sending mail, then with some likelyhood you are also running EC2 where wasting a couple of CPU cycles is beneficial for Amazon :-)

If it works like they say, this is a godsend. Email is a royal pain and the pricing of SES is well below market rate. Postmark (http://postmarkapp.com/) is similar and is $1.50 per thousand, compared to $.10 per thousand from Amazon.

Mailchimp appears to be offering unique emails from $5 per thousand! They appear to have significant discounts for emailing lists, but even at $12903 for 24.8 million emails, that's still $.52 per thousand.

http://www.mailchimp.com/pricing

Data transfer rates still apply for Amazon, but still... am I missing something?

Yeah but don't forget you are buying MailChimps' UI for that too. It may not be the best but it's definitely usable for a non-technical user.

However for your own custom interface this is going to be the obvious choice.

I really like Mailchimp, but it's just not geared for high-volume sending. If you were going to be sending into the millions, you would typically be looking at someone like Lyris or Silverpop.

Edit: Mailchimp does a really good job of holding your hand and providing support. Amazon SES does not even provide basic analytics like open rates and click tracking.

I think they are more for the mom-and-pop business who wants an email list, not web apps that need to send email (which was always a sore spot for EC2 customers). That's why I compared it to Postcard, which is directly marketed as email for web apps. It would certainly be possible to run a Mail Chimp-esque email list with this, but it would take a lot more technical know-how (at minimum you need to create your own views for subscribe/unsubscribe/send). Or at least it will until someone starts selling a wrapper around it for a small mark-up...

These are not really comparable products.

MailChimp is an email broadcast and subscription management service. It's for sending things like email newsletters and marketing campaigns.

SES/Postmark/Sendgrid are more for one-to-one type communications, e.g. delivering your application's forgot password email.

Ah, thanks for that clarification.

However, I would have thought that the "one-to-one type communications" would be more expensive (per email), than sending to lists. Amazon seems to allow both, at a much lower cost.

Yeah, well keep in mind a few things:

* Until today, MailChimp was by far the cheapest option, esp. if you compare them against similar services, e.g. Campaign Monitor.

* Mailchimp is a lot more than a dumb email server...it's a list management service, it offers stats, a pretty robust API, etc. You'd have to spend a lot of time to build up those capabilities around SES.

* I'm not sure SES is meant to handle the volume MailChimp handles. (I don't mean technically, I more mean what is allowed by Amazon.)

Just a few thoughts from a pretty well satisfied MailChimp customer. (I'm also a SendGrid customer, and you can bet I'll be taking a close look at SES as a replacement for that service.)

I haven't seen SES yet, but if it's anything like the rest of the AWS suite, they're not entirely comparable. Amazon's products are complex, and their statistical reporting focuses on the bottom line numbers, rather than detailed, action-based reporting. For example, Postmark app provides a nice interface for managing bounce emails. From the SES FAQ, it appears that they simply forward bounces on to an address that you specify. One could build a Postmarkapp-like service on top of SES, but SES is not a direct replacement for Postmarkapp.

One of the things Amazon is doing differently is offering complete control of the email headers. I've recently been evaluating some services and many don't offer this. I don't want to send marketing emails, unfortunately I have a service provider who uses e-mail as an integration strategy (instead of rest or anything similar). AWS does fill a niche for me, although I imagine that my particular niche is tiny. Although part 2, ill be hooked and using it for other email services soon.

Seems Amazon wants to fight it out with Google, by matching the new services with Google App Engine's free quota.

$0.10 per thousand in SES -> $0.0001 per email recipient // Same as in GAE.

You can send 2,000 messages for free each day when you call Amazon SES from an Amazon EC2 instance directly or through AWS Elastic Beanstalk. // Same as in GAE.

This, along with the recent AWS Elastic Beanstalk release and Amazon's intent of making Java hosting easy and without restrictions (http://news.ycombinator.com/item?id=2119104) all point to the day when I will be able to upload my Python app on GAE directly onto a pre-configured Amazon service (possibly making use of AppScale or TyphoonAE), which internally uses all these new services with free quotas.

It will be interesting to see how Gmail treats email messages from Amazon SES.

To add to it, it is not that I want to switch from GAE to AWS now. But, to know that it will be easier in case I need to, makes it good news.

I also believe competition which facilitates such migrations not only validates the space and the standard (write for GAE, you can host it on Google or on AWS), but also helps drive innovation and service levels.

I actually doubt that they really care about competing with Google App Engine. I mean, AWS has NetFlix, New York Times, Dropbox among their customers and GAE has.... who?

What I do think is that services like GAE have set a standard for the ease of use and price. People are now looking for free tiers, instant deployment, and traffic-based pricing. Customers are expecting Amazon to provide the same and so they do.

I like this. They are priced at 25% of sendgrid, which we use as we send a million emails a month or so. But sendgrid provides a dedicated IP address. Having a dedicated IP over a period of time helps with delivery as the IP 'reputation' increases based on your delivery rates.

A lot of EC2 Ips are blacklisted by ISPs because people just create instances and spam away using exim/sendmail. If amazon and keep its IPs clean and also manage the service well, this is going to be THE email sending service to use.

I'm in a similar situation. Sending hundreds of thousands a month with SendGrid, and while it'll be more than Amazon, I think the dedicated IP makes it worthwhile.

It amazes me how quickly AWS iterates and adds new features. Also, this is just what I needed for a site I am building (I was trying to figure out which third-party mail provider to use.)

One of my coworkers remarked that it's amazing how Amazon just takes their existing infrastructure and repackages it to be sold as a service. When you look at it as something that they already had built for themselves, while still being awesome, it helps keep perspective.

That's not how AWS works at all.

Werner Vogels (Amazon's CTO) explains it well here:

http://www.quora.com/How-and-why-did-Amazon-get-into-the-clo...

And the history is well presented here:

http://itknowledgeexchange.techtarget.com/cloud-computing/am...

The tldr; is basically that AWS was a skunkworks project within Amazon with its own completely separate infrastructure. Its success is mostly independent from Amazon.com's success. (Amazon.com funded it but mostly left it alone until it hit it big.) As Vogels points out, within 2 months of launch AWS would already have surpassed Amazon's excess capacity. I imagine now with some of the huge customers such as Netflix and NYT on AWS the AWS traffic may dwarf Amazon.com's.

So I was immediately looking at their REST API...

And true to form, Amazon adds yet another slightly incompatible request signing method.

Consistency is for wimps.

I dare you to look at the API for some of the "traditional" email service providers. I've had the displeasure of working with a few from some of the big names and they are real DailyWTF material.

The API does not seem to be bad, really. It's just not consistent with other AWS APIs, which would simplify writing language bindings for them.

I have worked with Constant Contact and it was a Constant Headache. My favorite was when they took the API down for maintenance and maintained HTTP 200 OK status codes for requests but instead of XML returned it was an HTML page saying they were down. I took a screenshot of the page because it was so surprising:

http://www.jongales.com/blog/2009/10/17/constant-contacts-in...

EmailLabs/Lyris decided to invent their own XML-over-HTTP API format rather than use REST or even SOAP or anything else you might already have a library for. They combined this with a very poor understanding of how XML is supposed to work (lots of <DATA> tags) and return results that aren't guaranteed to validate. Dates are represented in one of six different formats depending on which particular function you're calling. If there's a problem, you might get an error, you might get back nothing. I could go on.

Silverpop is similar.

Have you had any experience with Exact Target, at the API level or other? And don't get me started about a certain email broadcaster vendor out of Seattle that starts with "what" and ends in "counts"... their idea of XML is to parse an entire file line-by-line and treat each line independently of the whole. So it kind of looks like XML... to a kid who just learned Java I suppose.

Care to explain what you think about Exact Target - I might have to deal with them and would appreciate any feedback you have of them.

I'm in the same boat as you. :)

Without providing a biased opinion I thought the following link might help with your understanding of the ExactTarget API capabilities and structure - http://wiki.memberlandingpages.com/API_References

Hope this helps!

Um, postmark? It's an extremely simple API to implement.

You can easily integrate it with postfix

http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/...

That is awesome. So even without third part libs supporting this API I will be able to use this service

I wonder how well their mailing reputation is for high deliverability with this new service.. I've heard that mailing from EC2 was almost pointless due to its low reputation score

After reading through the guides, this is the most simple and clear exposition of email deliverability and reputation I've ever come across.

http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/...

(The mailchimp guide is also nice, and very extensive http://www.mailchimp.com/articles/email-delivery/ )

Seems like they'll like use a completely different IP range than EC2, and there shouldn't be any problems.. lets hope

I work as an engineer for an email service provider. I can tell you that deliverability is one of the core things you bring to the table when you are doing sending for a lot of people. It's the sloppy, people oriented aspect that developers ignore (imagine you've got a huge send going out and gmail just flagged you as a spammer, you better have a contact there to fix it fast). Sure, you can write an app to send a million emails in a few minutes, but your work (and bandwidth costs) are pointless if it never makes it to the customer's inbox.

There are a lot of dirty details in sending at volume. But like the old saying goes, "where there's muck, there's brass."

I suppose this will hurt the competition, sites like sendgrid and mailchimp.

I haven't been managing our email messaging, but this seems considerably cheaper than Sendgrid which charges something exorbitant (I mean, its like $80 a month, but they're f*cking emails).

Does anyone have a perspective on whether their service is just as good?

I don't think it will kill off the likes of SendGrid. It might actually help expose Email-as-a-Service to potential customers who weren't aware that those companies existed. In the end it could expand the market for everyone and end up benefiting the competition as well.

Pick an Amazon Web Service and for most (all?) there are several standalone companies competing on quality, customer service, and ease of use.

The problem for the competition is that Amazon's suite of services is getting more and more comprehensive and using ALL of their offerings really does lower development overhead (versus picking and choosing the best standalone Email/Queue/Storage/CPU offering).

It might just help them. If Amazon just undercut their infrastructure costs, they can ditch their own servers and simply route mails through Amazon.

Regardless, MailChimp does a lot of stuff besides just sending mail. I suspect that most of its customers are there for the list management and campaign management pieces rather than just the .send() bit.

AWS' pace of innovation is simply stunning. It shows that the business is not an afterthought for Amazon but rather treated as being of the same importance as their core business.

Compare that to AppEngine and you have to say they leave them behind in the dust. (I know it's not an Apples to Apples comparison.)

On the topic of sending e-mail, I discovered the following note on my utility company's bill payment page. I'm guessing they have never heard of SendGrid or the like.

http://posterous.com/getfile/files.posterous.com/dennis/GGBF...

(They did not reply to my friendly e-mail about it. Or perhaps their box was over quota...)

Obvious followup: "Amazon Simple SMS Service". Watch out Twilio...

They announced they'd support SMS when the launched SNS awhile back, so I don't think this would surprise anyone.

> Start sending email in minutes through Amazon SES using the AWS software development kits for Java and .NET

I've said it before, and I'll say it again: the java ecosphere in terms of libraries and resources is unparalled.

Perl/CPAN wins hands down.

And I am both a Perl and a Java programmer.

Well, except in code quality.

There's some awfully shady Java code out there, but since it looks impressive with all those abstract bases and factories you can't see the real problems.

A 12,0000 line Java program with the same features and the same bugs as a 500 line Perl script is going to look clean in comparison even though it's just as crappy.

Sure, but in case of Perl the shady code is on a big pile with the good code. In Java you have projects like Apache commons that generally produce fairly good code as long as you steer clear of the experimental stuff.

Sure, but in case of Perl the shady code is on a big pile with the good code.

Does Java have anything comparable to CPAN Testers? http://www.cpantesters.org/

Note that commits to Perl 5 get tested against the whole of CPAN for unintentional breakage.

Yes - CPAN is tremendous. I don't understand why perl is not more popular for this alone.

I'm not so sure Sendgrid, Postmark, and other email senders should be shaking in their boots.

There's plenty of other businesses that leverage AWS technology and resell it for a higher price. I bet they add AWS as an option as a value added reseller.

If you have an existing email host integrated throughout your site, it might make more sense to just stick with them.

It will force them to lower their prices though.

Agreed. I use Silverpop for high-volume sends even though I pretty sure they're just a front-end for PowerMTA

We used to use SilverPop but then we just bought a PowerMTA license and wrote our own front end. If you are a small company with a large list, SilverPop is too expensive. Amazon is cheap but it doesn't look like it has any mailmerge (email personalization) capabilities.

If you don't mind my asking, how much of a pain is it dealing with spam complaints and deliverability issues on your own versus through Silverpop?

The pain is all up front. You configure PowerMTA to slow down its sending due to the responses of the various email providers so they never block you. As the trust for your ip goes up you can send at a faster and faster rate. Also you then store all the email bounces and run a cron job to clean your list. Usually I stop sending to emails that return hard bounces and ones that have soft bounced three times.

bye bye postmarkapp, critsend, sendgrid, authsmtp, cloudsmtp ...

I don't know about that... In preparing to launch a high volume email startup, I have a few problems:

* How reputable are Amazon's IP's? Will my emails get flagged as spam due to reuse and general abuse?

* Another cranky API to use. Why not STMP?

* Sendgrid (and several others) have wonderful built in statistics and other quick n' easy apps.

* Also, those services' core business is deliverability, not volume. I feel AWS's offering may be the other way around...

There is really no excuse to not launch a web application!

This is excellent. I recently moved a production website to EC2 at the last minute due to contractual disagreements with a hosting vendor. My next step was to sign up on SendGrid and configure postfix to use that for emails, SES will be better integrated into the AWS ecosystem.

As a lot of you may know, emailing out from EC2 is mostly impossible as all ISPs bounce them back

I want to be excited about this, but amazon basically destroyed any trust I had in them (at least the people that handle AWS). I signed up for the amazon free usage tier of AWS, excited to try it out, and really really loving amazon for doing something like that (giving away service for free).

I signed up, spun up an EC2 instance (careful to make sure that this really was free), checked it out for a few minutes, then moved back to my linode and slicehost boxen. I was excited to have another spare machine to try stuff out on for the next year (I really wanted to try nginx as a reverse proxy).

About a month later, I got a bill for $60 from amazon. I tried to find a support chat for AWS (like what slicehost has), but couldn't...tried to find a way of calling them...but couldn't. Finally I sent them some sort of feedback saying "Hey, was this a mistake? Why are you billing me for something that is free?"

The response that I got back was something like "The cost for AWS is $60/mo! Thanks for using AWS!"

To me, this is absurd, and is borderline fraudulent (although I'm sure it was a mistake). Luckily for me, I have a good job, and while eating $60 worth of amazon making a mistake is annoying, it isn't a catastrophe. This wouldn't have been true for me while I was in school though, and wouldn't be true for some of the friends I recommended give AWS a try.

I'm starting to think that stuff like this is where "the cloud" falls apart on people. If I have a problem with my Verizon Business internet, I can call them and talk to somebody until it's fixed. If I have a problem with one of our AT&T telephones, same thing. If the power goes out at our building, I can call down to APS and find out why.

From what I can gather, this absolutely isn't true for google, or amazon, or any of the other "cloud" providers. If I build an email system myself, buy bandwidth/power/rackspace from a colo myself, and manage it myself, there aren't going to be any surprises. If it goes down, I can just look at why. Nobody is going to surprise me with a bill (except maybe the colo).

To be honest, amazon, I don't even plan on building anything on your platform...ever. Same goes for you, google. While I really really love the idea of cloud computering (or elastic computering), I definitely don't love the idea of some faceless company with no customer service of any kind who can arbitrarily just take money from me and doesn't care if I leave.

To me, stuff like this is a massive step backwards.

While not related to AWS, but more "the cloud" in general...look at what happened a few months ago when facebook's OAuth system bailed out for a few hours. Anybody dependent on facebook for login handling was simply SoL without really anything that they could do to solve the problem until facebook fixed it.

How is this desirable?

There was an article here yesterday (an it seems like something like this pops up just about every week) about how the days of the system admin are over. I wouldn't be so sure. You can yell at system admins until you feel better, you can call them endlessly at 3:00am until they wake up, you can tell them that they have to come in to the office RIGHT NOW and fix it RIGHT NOW. (I'm a sys admin, btw)

You can't do this to amazon, you can't do this to google. If amazon email service bails out...sorry, but call back later and maybe it will be fixed.

  Why are you billing me for something that is free?

Can't really respond to that, though as a paying customer, and someone who knows many people who've used the free tier, I would imagine it was a mistake on your end, although maybe they should have been more clear on Ts&Cs or something. Hard to say without knowing more.

  or any of the other "cloud" providers

Google are (in)famous for that problem, AWS I can't honestly say I have any experience with it. But don't just assume it's because they are "cloud" providers. Actually, it's because they are huge companies that, thanks to the (usual) efficiency of their products, can pretty much get away with it.

You say you use Linode and Slicehost, their services are the same as Amazon's EC2, yet you presumably know that their support is pretty great.

I've been testing PHPfog recently and their support, even in beta while I've been paying nothing to use them, has been excellent.

Examples go on and on... it's about the specific companies, not the type of service.

>AWS I can't honestly say I have any experience with it.

I can honestly say because I do have experience with it. Maybe it was something I clicked, but that is classic bait and switch. I would have never even considered AWS if it wasn't free and definitely didn't intentionally buy anything from them (as I said, I already have linode and slicehost, which is more than I need).

I'm not sure where you're going with this. I'm not saying that absolutely every cloud services provider is terrible, I'm saying that my perception of google, and my experience with amazon, is that they are.

Check the activity usage report. They break down in quite a bit of detail where the charges are. You can break it down even further by hour. I've used the Free Tier with no charges for over a month now, and have been pretty happy with it.

The one thing the Amazon Free Tier does charge for which is strange is regional data transfer (transfer between machines on AWS), but they provide you with 15GB of internet data transfer. Very odd.

From the figure ($60) it seems you probably launched an m1.small instance instead of a micro instance. IIRC the free tier only covers a micro instance and those amount to only $14.40/mo when run 24/7.

I'm pretty sure that if you downloaded your usage logs, you would know exactly how the money was spent (it's tedious, though). Link posted by frisco above: http://aws-portal.amazon.com/gp/aws/developer/account/index....

If I recall correctly the free tier enables you to use one micro EC2 instance. $60 for a month sounds about the cost of a small EC2 instance.

I'm pretty sure I know why it's happened to him:

Basically micro instances are ESB-only and if you select distro intended for instance storage the first option on the list in the wizard is "Small instance."

> About a month later, I got a bill for $60 from amazon.

...sounds like you launched the wrong instance type (specifically "small" instead of "micro"). Unfortunately that's easy to do, since small is the default in most cases. From what I remember the docs regarding free usage aren't too emphatic about this issue.

It's hard to out-and-out call this "user error", but I also don't think it's bait and switch. Mostly just poor documentation on amazon's part that contributed to a less-than-sufficient level of understanding on yours.

Well you have to love Amazon's focus on KISS (keep it simple, stupid) -- heck it's even called the _Simple_ Email Service! I can only imagine the number of (illustrious) tech companies that would have tried to dress this up like a revolution in computing.

Does anyone recommends a self-hosted webapp to manage and send the newsletters through AES/SendGrid/etc?

I would love to use mailchimp or campaignmonitor, but I only have users, not customers, and the high price ins't justified.

It seems like Amazon is friendlier than SendGrid about bulk marketing email.

Does this lower the barrier to entry for MailChimp/Constant Contact/Consumer Newsletter Service competitors?

Or are there other high technical barriers as well?

The future: Everything run by Google and hosted by Amazon.

plus: Everything you need to own, you buy at Amazon (rhymes!)

hopefully, this improves the deliverability of email that originates within amazon's environment. the service can be easy, but if the messages aren't getting through, then there is no point and sendgrid and others will continue to survive.

Amazon's IP's have terrible email reputations and are blocked by lots of services. Unless they are opening up a new block of IP's, I'd be very concerned about my deliverability rates. SendGrid give me a dedicated IP which helps a lot over time.

I can't find it but can you send attachments as well?

Attachments aren't actually a separate field in the email. They're base64'd binary data at the end of the text field.

Yes, there's a SendRawEmail action (http://docs.amazonwebservices.com/ses/latest/APIReference/AP...) in the API, which allows you to send a multipart MIME message.

considering the fact that 95% of all email is spam, the email service providers should implement a similar quota system to fight spam. actually it would be great if entire email ecosystem had something like this in its core.

no attachment support.. no mimetype support for anything but text and html.. not evident from the docs.. just errors when you try to send a jpeg

definitely still in beta

they are seriously taking over the world

I guess this is a great opportunity for individuals to provide services like aweber, mailchimp etc. Think about it, now you don't need to worry about the hardware. Provide a killer interface, make it super super easy and have a low monthly fee and let the user pay the amazon bill. ofcourse there are multiple revenue models but now is the opportunity.

It is also now simpler to create competitive alternative to mailchimp as you can just focus on the user experience and features rather than delivery. Great opportunity for startups.

Already on to it! http://www.emlr.co.uk

Reply on news.ycombinator.com