You can configure Simple Notification Service (SNS) feedback for an entire domain. Select one of your domains and expand the Notifications section. You can select an SNS topic for bounces, complaints, and deliveries. This is the most straightforward way to enable SNS feedback if you want to treat all email for a domain in exactly the same way.
Address-Specific SNS Configuration
In some cases, you should not treat all email in the domain in the same way. For example, you might have different software environments (dev, staging, production) that use the same domain, but send from different email addresses. Email bounces from Dev should go to developers, bounces from Staging to QA, and bounces from Production to the customer service team. You also might use the same domain for email marketing (not a great idea), and that feedback should go to the marketing team. You can configure each verified email address in SES with a different set of SNS topics.
Amazon Simple Email Service (SES) is a lean, low-cost option to send bulk email. However, the low cost of SES comes at a cost; it lacks many features that are built into SendGrid or other email services. You have to build your own “features” with combinations of other AWS services. The figure below summarizes some useful integrations that provide monitoring and feedback loops.
The Dashboard you see in SES is very primitive, with a very limited time series of data. CloudWatch allows you to create your own dashboard to monitor critical parameters, such as bounce and complaint rates. SES will put you on probation or terminate your service if you are suspected of sending spam. CloudWatch also lets you set events that will be triggered when a threshold is crossed.
Kinesis Firehose to S3
Kinesis Firehose is a “data bus.” It accepts data from various sources, transforms it (if necessary), and passes it on to other endpoints. In the context of SES, you can set up a Kinesis Firehose to push email notifications into Amazon S3 storage. It automatically creates a datetime-based folder hierarchy within S3 and stores a JSON file for each event. This maze of folders makes it rather hard to navigate the data by hand.
Logging email events to S3 is not very useful, in my experience, but there might be use cases that I haven’t thought of. Maybe you could set up an AWS Lambda function to watch for abuse notifications that appear in a bucket and take some action-but if you are doing that, you might as well use SNS to send directly to Lambda.
Simple Notification Service
Simple Notification Service, or SNS, is probably the most useful destination for SES data. A SES configuration set can send data directly to an SNS topic. An SNS subscription can listen to one or more topics and send data to a destination, which is one of the following:
Platform application endpoint
Personally, I like the HTTPS endpoint the best. You build an API endpoint that receives email feedback, and SNS will POST JSON to your endpoint every time an email bounces or a complaint is registered. Then, your application take immediate action to flag the address and stop sending to it, which is good for your sending reputation.
Amazon S3 is widely used as a repository for backups. Backups are an important aspect of a resilient system, but they are also a potential security vulnerability. Unauthorized access to a database backup is still a PCI or HIPAA violation. The permissions on Amazon S3 should be configured to minimize access to critical backups. My strategy is to use IAM to create a backup user with no password (cannot log in to AWS) and a single access key. The backup user’s access key is used to put backup files into S3. The S3 bucket policy is configured to allow “write-only” access for the backup user. The backups cannot be obtained, even if the backup user’s credentials are compromised.
It is fairly difficult to figure out how to create a “write only” bucket policy. The policy shown below is the “write only” policy that I use. It consists of two statements: BucketPermissions gives a user ability to locate the bucket (necessary to do anything in the bucket) and list its contents (to verify that a backup was written). You may remove the s3:ListBucket action if true write-only access is desired. The statement called ObjectPermissions allows the user to create objects in the specified bucket.
It appears that the file is being downloaded, but in fact only an empty file is created! While it is generally a bad idea to allow unauthorized users to guess file names, it is not a real problem in this case, because the backup user’s credentials would have to be compromised even to confirm the existence of a file stored in S3.