Database storage is mainly the space allocated for storing all your data (contacts and associated meta data, delivery statistics, and analytics) as well as the costs involved in querying and analyzing this data. To illustrate, if a user adds 'red shirt' to their wish-list, you attach the tag 'red shirt' to that user. You can attach as much metadata as required to each user. You can then analyze all this data to send targeted messages.
Every chunk of metadata occupies a tiny space in the database. 1 GB can hold about 1 million+ metadata points. 10 GB should be more than enough for most users. Heavy users - those sending more than one million emails every month - must expect overages.
API rate limits?
This is the rate at which you can call the Send With SES Contacts API. This API is usually called to add/update contacts and to attach/detach tags (metadata) to contacts.
For example, a rate limit is 300 requests/minute lets you do a steady rate of 5 calls per second or a single burst of 300 calls in one second or anywhere in between. The total API calls must not exceed 300 in 60 seconds.
NOTE-1: API rate limit is a soft limit for paid plans, meaning you can do short bursts that exceed the rate limits as long as you are not abusing our systems. Write to us if you are not sure.
NOTE-2: API rate limit is independent of your Email/SMS sending rate. Email/SMS sending rates are determined by AWS. For example, if your AWS SES email sending rate is 250/second, you can send up to 250 emails per second even if you are on the 'Free Plan'.
How scalable is Send With SES?
Send With SES operates on a globally distributed and scalable server infrastructure allowing it to handle very high concurrent message traffic. Our back-end infrastructure spreads across three clouds (AWS, GCP, Cloudflare) and is designed for >=99.95% uptimes.
Does Send With SES offer any inbox delivery guarantees?
Short answer: NO.
Long answer: Send With SES forces some industry standard best practices upon you like having a domain with SPF, DMARC, DKIM records in place before you can send emails. While these practices create trust with email service providers, the ultimate decider in inbox placement is the content of your email. Email recipients are only too happy to mark unsolicited emails as spam or click unsubscribe, resulting email service providers banning you.
If you are a genuine sender, our best practices along with our InboxVISA™ tool helps guide your emails safely into user inboxes.
Ultimately, the only one who can guarantee safe inbox placement is YOU.
Why does Send With SES need the IAM Full Access Role?
In the early days of Send With SES, we asked full access permission only for SES and SNS. Send With SES is in a constant state of development. As we kept building the product we wanted permissions for S3 to store email images and SQS to queue email delivery notifications for further processing. Sometime later we wanted CloudWatch access to hold and process SMS related delivery notifications.
We also expected AWS to introduce breaking changes and wanted to be ready in such cases. Not surprisingly AWS sent everyone the following message a few months ago. (They later rolled backed on this requirement.)
"We are reaching out to notify you that AWS Managed Policy is making a change that will require your action. AWS Managed Policy is deprecating the managed policy "CloudWatchFullAccess" and replacing it with "CloudWatchFullAccessV2". After December 7, 2023, "CloudWatchFullAccess" will no longer be supported."
How do we provide an uninterrupted and seamless experience to end users when we have to constantly keep asking them to add specific permissions every now and then. This was not at all user friendly. Both end-user experience as well as product development suffered.
So we decided to ask only for one permission - IAM Full Access.
Some people were/are unhappy. Somehow their assumption was, "If we give you IAM Full Access you will misuse it.", or, "Your servers will get hacked and those hackers will do something bad." Understandably, these are valid assumptions, no different from, "Do not build a flying machine because it might crash."
We believe transparency and a proper explanation will convince some people and no amount of explanation will convince other people. To those people who are considering to use Send With SES, this is how we handle things.
Send With SES accesses your AWS Account by requesting a set of temporary keys using the 'IAM Role' provided by you. This is the recommended best practice by AWS. No third parties can access your account.
IAM Full Access is something similar to full admin access. It gives Send With SES the power to provision any resource within your AWS Account. However Send With SES only provisions resources which are required. Currently these are - SES, SQS, SNS, S3, Pinpoint, CloudWatch.
You can delete the IAM Role at any time to prevent Send With SES from accessing your AWS Account.
It is highly recommended you create a separate AWS Account exclusively for Send With SES. This way you can be sure that any resource launched within this AWS Account has been provisioned by Send With SES.
Data retention only applies to idle accounts. An idle account is one that has not sent a single email or sms in the last 90 days.
You contacts and contact meta-data (tags, events, etc.), campaign statistics, email templates, images and files - all count towards your data. This data is automatically deleted
Data All data Data retention is mainly Storage space is mainly intended for images and files associated with your emails and for storing contacts and associated metadata in the database. For example, if a customer adds 'red sneakers' to their wishlist, you attach this information to the contact. You can attach as much metadata as required to each contact. Each bit of metadata occupies a tiny space in the database, around 1 KB. 1 GB space can hold about 1 million metadata points.
NOTE: For paid plans, storage space is a soft limit, meaning you can store more than your allowed limit as long as you are not abusing our systems.