Estimating Bandwidth for the Cloud

 
When you move an application onto a platform in the cloud, you will be paying utility-style prices, which are "pay as you go." Thus, you need to estimate those costs up front. In addition, you'll need to estimate whether the additional load on your connectivity will require a bigger pipe. Here's how to do it. 
 
Putting an application into the cloud can happen in at least two ways. You can do it as Software as a Service (SaaS) or you can put it on a Platform as a Service (PaaS). If it's SaaS, such as hosted Exchange, you'll usually be charged for the service, not for the underlying processor, storage and bandwidth. But if you put an application on a platform, you will be charged for those underlying items. This article addresses how to estimate bandwidth when you're putting an application onto a platform. It also shows you how to estimate the load on your connectivity.
 
Bandwidth is usually measured in one of two ways, and both of them are needed when moving to the cloud. Measuring total usage in kilobits (or Megabits)per second will tell you what size Internet access connection you need. Measuring bandwidth in total number of Megabytes sent and received by the server per month will predict your charges from the cloud provider.
 
In this example, we're using Microsoft Exchange as the application. This may be a bit strange, since ordering Exchange as SaaS almost always makes more sense than putting an Exchange server into the cloud, but the for purpose of estimating bandwidth, the example works fine.
 
 
There's a nice, long article on TechNet that describes estimating remote office bandwidth for Exchange in detail, and we're basing this article on that. It's at
 
We have been comparing the numbers in that article with our own data on our current hosted clients. So far they certainly seem in the ballpark.
 
The numbers are based on Exchange 2007, but we’ve seen no reason to believe bandwidth requirements increase for 2010.
 
The basic method for estimating any application's bandwidth requirement is to estimate the size of a transaction with the server and then to multiply this times the number of users and the number of transactions a day (based on the kind of user) . This will yield the number of kilobytes per day for each kind of user. It's then just a question of aggregating the numbers and converting them from total bytes to kilobits per second. Our example does it this way:
 
The bandwidth estimate is broken down into three parts:   (1) A definition of light, medium, heavy, and very heavy user,   then (2) average Kilobytes per day of usage that one would expect  based on the four classifications and type of E-mail client, and (3) the bandwidth that one might expect based on a 100 user organization under the various conditions.
 
  1. Definition of light to very heavy user
 

Activity
Light
Medium
Heavy
Very heavy
Messages sent per day
5
10
20
30
Messages received per day
20
40
80
120
Average message size (KB)
50
50
50
50
Messages read per day
20
40
80
120
Messages deleted per day
10
20
40
60
OWA log on and log off per day
2
2
2
2

 
  1. Bandwidth usage is
 

E-Mail Client
Light
Medium
Heavy
Very Heavy
Outlook (KB/user/day)
1,300
2,600
5,200
7,800
OWA (KB/user/day)
6,190
12,220
24,270
36,330

 
  1. Scenarios by classification 

Description
Bandwidth
Access
Usage
Users
KB per user per day
Average Mbps
High  Hour Mbps
MB per user per month
Outlook
Light
100
1,300
0.036
0.072
28.2
Outlook
Med
100
2,600
0.072
0.144
56.3
Outlook
Heavy
100
5,200
0.144
0.289
112.7
Outlook
V Heavy
100
7,800
0.217
0.433
169.0
OWA
Light
100
6,190
0.172
0.344
134.1
OWA
Med
100
12,220
0.339
0.679
264.8
OWA
Heavy
100
24,270
0.674
1.348
525.9
OWA
V Heavy
100
36,330
1.009
2.018
787.2

 
You can use this Table 3 to estimate your bandwidth requirements based on the number of mail-users you have and about how many would fall into each of the Usage categories.   The High Hour numbers assume a daily peak of twice the average usage.
 
Again, two expressions of bandwidth will be necessary for moving into the cloud, both in Mbps and in terms of total MB sent and received per month.

wholesale designer bags Good

wholesale designer bags

Good to the last drop.

cheap timberland boots

Obey your thirst.

cheap gucci shoes

The new digital era?

puma men shoes

Impossible made possible.

nike shox r4

Poetry Take time to indulge?

air max 2012

Impossible made possible.

The relentless pursuit of perfection.

authentic nfl jerseys

Ask for more.

nfl jerseys suppliers

The taste is great.

coach factory outlet

feel the new space.

coach outlet store

intelligence everywhere.

coach bags outlet

the choice of a new generation.

coach bags on sale

we integrate, you communicate.

coach handbags on sale

take toshiba, take the world.

coach outlet online

let's make things better.

4 Color Sticker

Bandwith in its basic form represents the amount of information that sent to and from readers across your website during a time period,4 Color Sticker usually calculated in per month.Full Color Sticker
 

4 Color Sticker

Bandwith in its basic form represents the amount of information that sent to and from readers across your website during a time period,4 Color Sticker usually calculated in per month.Full Color Sticker
 

Web Development

I think this is nice idea. I like the idea of it. I enjoy reading your article. I learn more. Thank you for the information that you share.

I concur! these bandwidth (or

I concur! these bandwidth (or Data Transfer) charges are certainly a very tricky part of the cloud billing equation because they’re harder to intuit. Some cloud estimating questions are relatively easy to answer: How many users do you have? How many servers will you need?

dapoxetine