Bandwidth quota

Posted August 4, 2013 17.5k views
I am a bit confused as to what counts towards the bandwidth quota. Is it only outgoing data from a droplet counts towards the monthly quota? What if I have more than one droplet, is the bandwidth pooled across all droplets? Thanks.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
4 answers
From Pay-As-You-Grow Pricing:
Q: Do you charge for bandwidth?
A: Yes. Plans start with 1TB per month and increase incrementally. Once the monthly transfer limit has been exceeded it is $0.02 per GB thereafter. Only outbound transfer is counted.
We only bill for outbound bandwidth. Bandwidth is not pooled across all droplets, it's specific to each droplet.

It looks like, if you had a high-bandwidth site that was low in other overhead, it would be cheaper (about half the price, actually) to serve the site on a bunch of $5 or $10/month servers with a load balancer, rather than using a single, large container.

Is structuring a site to take advantage of the cheaper bandwidth a violation of the TOS? Would it be unneighborly? I can see it taking up too many IP addresses, but what other technical issues might it cause?

Problem is that if your load balancer is also a $5 or $10/month server, you only have 1TB or 2TB outbound bandwidth. Unfortunately it seems to me that you cannot use the sum of all of your droplets bandwidth on one of your droplets (which is your load balancer).

  • Load balancing without a load balancer, that’s what round-robin DNS is good for. Use private networking to share state, etc between the servers.

    • This is not load balancing just “load distribution”. It is good for static content.
      But is it ensured that the same client is always sent to the same server? If not, in case of dynamic content backend servers will work continuously on sharing state job. Wouldn’t it be a big problem?

      • Oh, it’s balanced all right, what you are talking about is “sticky sessions”. Although I don’t recommend it, you can do sticky sessions by redirecting from the round robin address to an explicit back end. For example, “” resolves to 100 IP addresses on 100 back-end servers, numbered 0 to 99 ( … On each, incoming connections to “” get redirected to the explicit name of the server that received the request,, for example. Of course, that is what people will bookmark, and it breaks browser caching, so it’s not a very good choice.

        There are a couple of better approaches to take here…

        For new development, build your web app’s front end in Javascript, and push it out to the client, communicating to your back end exclusively through API calls. Done right, your app will be essentially stateless. Pivotal Tracker is a good example of this approach. This will scale effortlessly.

        For legacy apps, you can either push all state into an encrypted cookie, or share state through some fast mechanism like memcached, or a fast no-SQL like Mongo. I’ve done all of these successfully. However, if you are trying to scale legacy apps with lots of state, you should probably be rethinking your approach anyway.