How does Amazon SES calculate AttachmentSize and DataTransfer-Out?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







0















So, I have a list of 5400 users and I emailed them attachments of 550KB.
Total size of the email when received is 820KB.



In billing report I got the following:



> $0.54 for sending emails to all recipients ($0.10 per thousand) - ok
> $0.44 for 3.70GB in AttachemntsSize - how did they calculate this?
> $0.36 for 4GB of DataTransfer-Out - how did they calculate this?


Is there a way to predict these calculations in future sendings?










share|improve this question































    0















    So, I have a list of 5400 users and I emailed them attachments of 550KB.
    Total size of the email when received is 820KB.



    In billing report I got the following:



    > $0.54 for sending emails to all recipients ($0.10 per thousand) - ok
    > $0.44 for 3.70GB in AttachemntsSize - how did they calculate this?
    > $0.36 for 4GB of DataTransfer-Out - how did they calculate this?


    Is there a way to predict these calculations in future sendings?










    share|improve this question



























      0












      0








      0








      So, I have a list of 5400 users and I emailed them attachments of 550KB.
      Total size of the email when received is 820KB.



      In billing report I got the following:



      > $0.54 for sending emails to all recipients ($0.10 per thousand) - ok
      > $0.44 for 3.70GB in AttachemntsSize - how did they calculate this?
      > $0.36 for 4GB of DataTransfer-Out - how did they calculate this?


      Is there a way to predict these calculations in future sendings?










      share|improve this question
















      So, I have a list of 5400 users and I emailed them attachments of 550KB.
      Total size of the email when received is 820KB.



      In billing report I got the following:



      > $0.54 for sending emails to all recipients ($0.10 per thousand) - ok
      > $0.44 for 3.70GB in AttachemntsSize - how did they calculate this?
      > $0.36 for 4GB of DataTransfer-Out - how did they calculate this?


      Is there a way to predict these calculations in future sendings?







      email amazon-web-services






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 5 at 9:35







      RhymeGuy

















      asked Jan 29 at 15:16









      RhymeGuyRhymeGuy

      115114




      115114






















          1 Answer
          1






          active

          oldest

          votes


















          0














          Your attachments of 550 KB, once embedded in an email, are most likely base64 encoded. Base64 is an encoding scheme that makes binary payload safe to pass over transport services that may not pass clean 8-bit data -- an assumption still prevalent in SMTP. Base64 coding produces 8 bits of output for each 6 bits of input, so your attachment -- encoded on the wire -- would grow to 733.33 KB, and 5400 of them would be 3.96 GB.



          This is slightly higher than the billed 3.70 GB "AttachmentSize" so this is either a rounding error or SES actually bills in gibibytes (2^30 = 1,073,741,824 bytes, these are properly abbreviated GiB but very often casually abbreviated as GB) instead of actual gigabytes (10^9 = 1,000,000,000 bytes). 3.96 GB is 3.688 GiB. Either way, the billing number is very close to the predicted size, assuming base64 encoding.



          And the total size of 4.0 GB transferred out seems to be very close to the same value, rounded to an even gigabyte.



          Without knowing the size of the message body and headers, it's hard to say why exactly the email client is displaying a size of 820KB for the message, but assuming the message, on the wire, is indeed that size, it's still within the range of rounding errors because that adds up to somewhere in the neighborhood of 4.428 GB or 4.123 GiB (assuming it's 820 KB rather than 820 KiB, but that only introduces a margin of error of about 3% either way).





          The discrepancy between gigabytes and gibibytes is the reason why hard drives and flash drives are always smaller than they should be based on what you bought -- you were probably expecting something sized in GiB but what they sell you is sized in GB. Documented examples for AWS are hard to find but at least in some cases AWS does mean GiB when they say GB. GiB-based billing is more favorable to the customer since 1 GiB has more bytes than 1 GB.






          share|improve this answer
























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "3"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1399690%2fhow-does-amazon-ses-calculate-attachmentsize-and-datatransfer-out%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            Your attachments of 550 KB, once embedded in an email, are most likely base64 encoded. Base64 is an encoding scheme that makes binary payload safe to pass over transport services that may not pass clean 8-bit data -- an assumption still prevalent in SMTP. Base64 coding produces 8 bits of output for each 6 bits of input, so your attachment -- encoded on the wire -- would grow to 733.33 KB, and 5400 of them would be 3.96 GB.



            This is slightly higher than the billed 3.70 GB "AttachmentSize" so this is either a rounding error or SES actually bills in gibibytes (2^30 = 1,073,741,824 bytes, these are properly abbreviated GiB but very often casually abbreviated as GB) instead of actual gigabytes (10^9 = 1,000,000,000 bytes). 3.96 GB is 3.688 GiB. Either way, the billing number is very close to the predicted size, assuming base64 encoding.



            And the total size of 4.0 GB transferred out seems to be very close to the same value, rounded to an even gigabyte.



            Without knowing the size of the message body and headers, it's hard to say why exactly the email client is displaying a size of 820KB for the message, but assuming the message, on the wire, is indeed that size, it's still within the range of rounding errors because that adds up to somewhere in the neighborhood of 4.428 GB or 4.123 GiB (assuming it's 820 KB rather than 820 KiB, but that only introduces a margin of error of about 3% either way).





            The discrepancy between gigabytes and gibibytes is the reason why hard drives and flash drives are always smaller than they should be based on what you bought -- you were probably expecting something sized in GiB but what they sell you is sized in GB. Documented examples for AWS are hard to find but at least in some cases AWS does mean GiB when they say GB. GiB-based billing is more favorable to the customer since 1 GiB has more bytes than 1 GB.






            share|improve this answer




























              0














              Your attachments of 550 KB, once embedded in an email, are most likely base64 encoded. Base64 is an encoding scheme that makes binary payload safe to pass over transport services that may not pass clean 8-bit data -- an assumption still prevalent in SMTP. Base64 coding produces 8 bits of output for each 6 bits of input, so your attachment -- encoded on the wire -- would grow to 733.33 KB, and 5400 of them would be 3.96 GB.



              This is slightly higher than the billed 3.70 GB "AttachmentSize" so this is either a rounding error or SES actually bills in gibibytes (2^30 = 1,073,741,824 bytes, these are properly abbreviated GiB but very often casually abbreviated as GB) instead of actual gigabytes (10^9 = 1,000,000,000 bytes). 3.96 GB is 3.688 GiB. Either way, the billing number is very close to the predicted size, assuming base64 encoding.



              And the total size of 4.0 GB transferred out seems to be very close to the same value, rounded to an even gigabyte.



              Without knowing the size of the message body and headers, it's hard to say why exactly the email client is displaying a size of 820KB for the message, but assuming the message, on the wire, is indeed that size, it's still within the range of rounding errors because that adds up to somewhere in the neighborhood of 4.428 GB or 4.123 GiB (assuming it's 820 KB rather than 820 KiB, but that only introduces a margin of error of about 3% either way).





              The discrepancy between gigabytes and gibibytes is the reason why hard drives and flash drives are always smaller than they should be based on what you bought -- you were probably expecting something sized in GiB but what they sell you is sized in GB. Documented examples for AWS are hard to find but at least in some cases AWS does mean GiB when they say GB. GiB-based billing is more favorable to the customer since 1 GiB has more bytes than 1 GB.






              share|improve this answer


























                0












                0








                0







                Your attachments of 550 KB, once embedded in an email, are most likely base64 encoded. Base64 is an encoding scheme that makes binary payload safe to pass over transport services that may not pass clean 8-bit data -- an assumption still prevalent in SMTP. Base64 coding produces 8 bits of output for each 6 bits of input, so your attachment -- encoded on the wire -- would grow to 733.33 KB, and 5400 of them would be 3.96 GB.



                This is slightly higher than the billed 3.70 GB "AttachmentSize" so this is either a rounding error or SES actually bills in gibibytes (2^30 = 1,073,741,824 bytes, these are properly abbreviated GiB but very often casually abbreviated as GB) instead of actual gigabytes (10^9 = 1,000,000,000 bytes). 3.96 GB is 3.688 GiB. Either way, the billing number is very close to the predicted size, assuming base64 encoding.



                And the total size of 4.0 GB transferred out seems to be very close to the same value, rounded to an even gigabyte.



                Without knowing the size of the message body and headers, it's hard to say why exactly the email client is displaying a size of 820KB for the message, but assuming the message, on the wire, is indeed that size, it's still within the range of rounding errors because that adds up to somewhere in the neighborhood of 4.428 GB or 4.123 GiB (assuming it's 820 KB rather than 820 KiB, but that only introduces a margin of error of about 3% either way).





                The discrepancy between gigabytes and gibibytes is the reason why hard drives and flash drives are always smaller than they should be based on what you bought -- you were probably expecting something sized in GiB but what they sell you is sized in GB. Documented examples for AWS are hard to find but at least in some cases AWS does mean GiB when they say GB. GiB-based billing is more favorable to the customer since 1 GiB has more bytes than 1 GB.






                share|improve this answer













                Your attachments of 550 KB, once embedded in an email, are most likely base64 encoded. Base64 is an encoding scheme that makes binary payload safe to pass over transport services that may not pass clean 8-bit data -- an assumption still prevalent in SMTP. Base64 coding produces 8 bits of output for each 6 bits of input, so your attachment -- encoded on the wire -- would grow to 733.33 KB, and 5400 of them would be 3.96 GB.



                This is slightly higher than the billed 3.70 GB "AttachmentSize" so this is either a rounding error or SES actually bills in gibibytes (2^30 = 1,073,741,824 bytes, these are properly abbreviated GiB but very often casually abbreviated as GB) instead of actual gigabytes (10^9 = 1,000,000,000 bytes). 3.96 GB is 3.688 GiB. Either way, the billing number is very close to the predicted size, assuming base64 encoding.



                And the total size of 4.0 GB transferred out seems to be very close to the same value, rounded to an even gigabyte.



                Without knowing the size of the message body and headers, it's hard to say why exactly the email client is displaying a size of 820KB for the message, but assuming the message, on the wire, is indeed that size, it's still within the range of rounding errors because that adds up to somewhere in the neighborhood of 4.428 GB or 4.123 GiB (assuming it's 820 KB rather than 820 KiB, but that only introduces a margin of error of about 3% either way).





                The discrepancy between gigabytes and gibibytes is the reason why hard drives and flash drives are always smaller than they should be based on what you bought -- you were probably expecting something sized in GiB but what they sell you is sized in GB. Documented examples for AWS are hard to find but at least in some cases AWS does mean GiB when they say GB. GiB-based billing is more favorable to the customer since 1 GiB has more bytes than 1 GB.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 29 at 22:01









                Michael - sqlbotMichael - sqlbot

                1,013610




                1,013610






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Super User!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1399690%2fhow-does-amazon-ses-calculate-attachmentsize-and-datatransfer-out%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Paul Cézanne

                    UIScrollView CustomStickyHeader Resize height generates problems when scroll is too fast

                    Angular material date-picker (MatDatepicker) auto completes the date on focus out