I use Amazon SES and SNS for event notifications, but not EC2 or S3. My bill contains two line items that appear to represent the same outbound traffic: an SES charge for attachment data and a generic Data Transfer Out charge associated with usage beyond the monthly global free tier. The quantities are very similar.
AWS documentation says the data-transfer tiers are calculated using aggregate usage across services such as EC2, S3, RDS, SES, and SNS, which suggests SES traffic contributes to the shared 100 GB monthly allowance. What I cannot determine is whether SES-originated bytes are charged a second time under generic Data Transfer Out after that allowance is exceeded, in addition to SES's attachment charge, or whether SES traffic is excluded because it already has a service-specific attachment price.
Has anyone sent more than 100 GB through SES and confirmed from an actual invoice how these charges are applied?
2 Answers
The available documentation confirms that SES attachment data has its own per-GB charge, but it does not clearly answer whether the same bytes also appear under the aggregate Data Transfer Out pricing. The note about possible additional transfer charges is often written in the context of EC2, so it is not enough by itself to prove that SES traffic is billed twice. The matching quantities may indicate overlapping usage, but a real billing export or confirmation from AWS billing support would be needed to establish that conclusively.
One practical suggestion is to avoid sending large files as SES attachments when possible and instead store them in object storage and send a time-limited download link. That may reduce SES attachment costs, although it introduces storage and transfer charges elsewhere and does not directly resolve whether SES bytes count toward the shared transfer allowance.
That works for some use cases, but attachments are required for the recipients in this case. I am mainly trying to understand the billing treatment rather than redesign the delivery flow.
That is the ambiguity I ran into as well. Since the messages originate outside AWS, an EC2-based explanation does not apply, but the invoice still seems to show both measurements.