Unsurprisingly, one of the more complicated aspects of cloud expenses is network traffic costs.
Calculating your storage and compute costs is usually straightforward: there are fixed fees for storage (in GB), memory (in GB), and CPU (per core).
Networking is not so simple. You can pay by bandwidth or by traffic, the source and destination of the traffic matters, and prices vary by cloud product.
In this week's post, the first of a multipart series, we take a look at how network pricing works for Alibaba Cloud Server Load Balancers (SLBs).
Future posts will discuss pricing for:
There are also products like MaxCompute that charge their own network traffic fees. We may talk about those in future posts, if there is demand.
It's not all bad news and big bills! There are several classes of traffic that are actually zero-cost, including:
Which brings us to our first cost-saving tip!
Cost-saving tip: Keep traffic within Alibaba Cloud whenever possible, to avoid network egress charges
Just a quite note: unless otherwise indicated, prices are for Alibaba Cloud's Singapore Region. Prices vary from Region to Region. I have chosen Singapore because it is one of the more expensive regions, so you should actually end up paying less (with a few exceptions) if you choose another region.
There are two types of Load Balancer on Alibaba Cloud:
CLBs are designed for Layer 4 (TCP/UDP) and Layer 7 (HTTP/HTTPS), while ALB is a newer type of Load Balancer that only handles Layer 7 (HTTP/HTTPS) but with lots of additional routing features and better scalability. Let's focus on CLB first.
Internet-facing CLBs have two payment "modes" for egress traffic:
Pay-by-bandwidth charges you up-front for a fixed amount of bandwidth (measured in megabits per second - Mbps). For Singapore, the prices are:
This doesn't actually mean that your egress traffic can be arbitrarily high: it is limited by your CLB specification, and bigger CLBs cost more. I don't cover those other fees in this blog post because they aren't network related, but you can find them here.
Also, something that is often confusing for new users: this cost is per-Mbps. So the 0.006 USD above is for 1 Mbps worth of traffic! 2 Mbps would cost 0.012 USD, 3 Mbps would cost 0.018 USD, and so on...
Here's a table to help make the costs clearer:
The two middle columns show the amount of traffic (in Mbps) charged at 0.006 USD vs the amount charged at 0.02 USD.
The cost does scale with bandwidth, but relatively slowly.
Pay-by-traffic is "Pay-As-You-Go", meaning you are charged based on the actual amount of outbound traffic (measured in GB).
CLB charges a data transfer fee when you are using the pay-by-traffic payment mode. For Singapore, that fee is 0.117 USD / GB.
Again, the upper limit on how much traffic your Load Balancer can actually handle depends on its type (also called a specification), so there is a hard upper limit on SLB bandwidth. Bigger SLB instances have a higher threshold.
With Pay-by-traffic, you'll pay for exactly the amount of egress traffic you generated, in GB.
Application Load Balancers connect to the Internet using Elastic IPs. We will cover EIPs in a future blog post, so I'm going to skip over ALB for now!
Let's do an (admittedly unfair) comparison between Pay-by-traffic and Pay-by-bandwidth, just to help us understand the math:
You can see pretty clearly that costs scale much more reasonably for Pay-by-bandwidth, as long as we have constant egress traffic.
What would happen if we switched to a model where we have to handle 50 Mbps, but it only happens once an hour for 2 minutes? Of course, Pay-by-traffic wins in that scenario. Why? Let's do the math:
24 hours x 0.93 USD /hour = 22.32 USD
50 Mbps / 8 Mbit/MB * 2 minutes * 60 seconds / minute = 750 MB. That's our total traffic each hour. Over 24 hours that's
18,000 MBor about
17.58 GB. The total Pay-by-traffic cost is therefore
17.58 x 0.117 = 2.06 USD.
The TL;DR here is: Pay-by-bandwidth is good for both low and high bandwidth applications, as long as your average utilization is high. Pay-by-traffic only makes sense for bursty workloads that are also low traffic over the long term.
Let's do the math ourselves for a few more scenarios, just to cement what we've learned so far.
Your CLB is generating 4 Mbps of traffic 24 hours a day, every day.
Using the pricing model above, your cost over 10 days would be:
4 Mbps * 0.006 USD / hour * 24 hours/day * 10 days = 5.76 USD
Again, assuming 4 Mbps, 24 hours a day, if you used Pay-by-traffic in this scenario, it would cost:
4 Mbps / 8 Mbits/MB * 3600 seconds/hour * 24 hours * 10 days = 432,000 MB 432,000 MB / 1024 MB/GB * 0.117 USD / GB = 49.36 USD
So we can see that Pay-by-bandwidth is significantly cheaper here.
Let's re-do our math, except that now we will make different assumptions about our traffic.
Over a 10 day period, our traffic is essentially 0 Mbps most of the time, with two 10 Mbps "spikes", each lasting 2 hours (for a total of 4 hours at 10 Mbps, over our 10 day period).
Using Pay-by-traffic, our 10-day cost comes out to:
10 Mbps / 8 Mbits/MB * 3600 seconds/hour * 2 hours * 2 days with traffic = 18,000 MB 18,000 MB / 1024 MB/GB * 0.117 USD / GB = 2.06 USD
Using Pay-by-bandwidth, our cost for 10 days is:
(5 x 0.006 + 5 x 0.02) * 24 hours/day * 10 days = 31.20 USD
Here we see that Pay-by-traffic is cheaper in this scenario.
That's it for this week! See you next Friday. ^_^
Great! Reach out to me at
email@example.com and I'll do my best to answer in a future Friday Q&A blog.
You can also follow the Alibaba Cloud Academy LinkedIn Page. We'll re-post these blogs there each Friday.
JDP - October 15, 2021
JDP - November 19, 2021
JDP - April 23, 2021
JDP - April 22, 2022
JDP - April 16, 2021
JDP - April 30, 2021
Respond to sudden traffic spikes and minimize response time with Server Load BalancerLearn More
An all-in-one solution for deploying applications, building websites and blogs, and running web programs, starting from $3.50/month.Learn More
This solution helps you improve and secure network and application access performance.Learn More
An easy transformation for heterogeneous database.Learn More
More Posts by JDP