Your IP address might have a dirty history
Public IP addresses (of the IPv4 variety) are a scarce resource and AWS has to recycle them. EC2 instances are allocated a public IP address on start up which will stay the same until the instance “is stopped, terminated or replaced with an Elastic IP address“.
On any hosting platform, cloud or traditional, IP addresses tend to pass through a lot of hands before they reach you and in some cases the IP address that you have been allocated has been used for sending spam emails and is therefore on someone’s blacklist.
If you are not sending emails from your EC2 Instance to the outside world then this isn’t a problem. However if you wish to send emails from your instance then you will need to check your instance’s public IP address on services like Spamhaus, Trend Mirco and the Composite Blocking List (CBL). This isn’t an exhaustive list of spam blacklisting services, in all likelihood you will come across many others.
Getting your instance’s public IP address de-listed from a spam blacklist can be a challenging experience. Trend Micro for instance require that your IP address is marked as a static IP address before they remove it from their blacklist, to do this you will need to allocate an Elastic IP Address to your instance and then configure the reverse DNS for that IP address.
You will need to check the history of every public IP address that you want to send emails from. If the number of instances that you are operating is changing dynamically using Auto Scaling then this could be a challenging task. One solution might be create a single instance as your public SMTP server and then configure all your other instances to use that as a smart host.
Lastly if you are sending a substantial number of emails from your EC2 instance then you will need to apply for your email sending limits to be removed.
It’s possible to send emails from an EC2 instance without fearing that it will be marked as spam, AWS give you all the tools that you need, but it might just be more effort than it’s worth.
Simple Email Service to the Rescue!
Simple Email Service (SES) saves you the effort of creating your own email platform for your applications. You don’t need to worry about keeping IP address off blacklists because AWS takes care of that for you. You also don’t need to worry about availability, SES runs on multiple availability zones meaning that you are very unlikely to ever experience a total failure. SES is scalable, assuming that you are trustworthy, you can send tens of thousands of emails through SES very rapidly. And best of all SES is probably going to cost you next to nothing.
You can connect to SES using an SMTP Interface or through an API that can be used from most languages such as Java, .NET, PHP, Ruby, Etc. It is likely that your existing application uses SMTP so the SMTP Interface is probably going to be easiest to implement to begin with. If you do choose the SMTP route you may want to configure your existing email server as a smart host to SES because you can abstract the process of authentication to SES away from your application which means that you don’t need to change the code of your application.
I’m convinced that Platform as a Service offerings like Elastic Beanstalk are the future. So I would really like to see AWS offer the ability to configure the Elastic Beanstalk environment with SES SMTP credentials. This would mean that the local SMTP server on each instance in your Elastic Beanstalk environment would have a Smart Host that was pointing to the SES server. It’s worth pointing out that this can be achieved today manually by creating your own custom AMI for Elastic Beanstalk.
I’d like to stress again that IP addresses having a dirty history is true of any hosting platform, I just highlight the problem here because AWS provide you with SES as simple solution to do something about it.
Basically it is likely that a team of developers and support engineers can make a better job of creating an email platform than you can.
If you are currently using AWS then SES is probably the logical choice and even if you are not using AWS today you should strongly consider SES for sending Emails from your Web Applications.
Please feel free to share your thoughts with me.