• Type: Epic
    • Status: Open (View Workflow)
    • Priority: Blocker
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s:
    • Labels:
    • Epic Name:
      Bandwidth limiting in


      Implement strategies that will help reduce bandwidth used by customers.

      The concepts are: showback/shameback/chargeback.
      The key ideas are thus:

      1. Showback: Start collecting information about how much bandwidth a client is using, and show it to them in the UI
      2. Shameback: Notify them that they are using an excessive amount of bandwidth. Some may not even know, and will self-regulate their activity.
      3. Chargeback: Take more aggressive action against the client, either require them to move to a bigger plan, charge them for excess usage directly, or cut them off

      Jake was working on a prototype for step 1. There is a point right after authorization for image download that the intent for the client to download an image is complete. Then the app server follows up with returning a signed download URL, either from cloudfront or S3. Jake's prototype was going to record the bandwidth consuming intent at this point. It is probably super-accurate in the 99% case. If, however, the client decides not to follow that redirect to the signed URL (e.g. in the case of Tejas' load tester) they will record bandwidth that they never consume.
      The only way to get 100% accurate information would be to see if Amazon can give it to us directly from s3 and cloudfront. In Jake's opinion, this is not worth it.

        Gliffy Diagrams




              • Assignee:
                jbeakley Jonathan Beakley
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: