Good morning,
I am looking into an inexpensive solution to deliver content to our European customers, I came across Amazon CloudFront. I was wondering if any of you had any experience using this service? If so, what are your thoughts compared to something like Limelight or Akamai?
Thanks!
I have no real-world experience using CloudFront, but on paper it strikes me as a viable CDN for medium or small volumes, and possibly high variation of volume over time, compared to Akamai's and LimeLight's offerings which may be better for steadily high volumes.
CloudFront is essentially a "pay per use" arrangement, and pricing is pretty transparent. For example, if in a typical month you serve about a million GETs from Europe and a million GETs from the US, each GET delivering about a megabyte, the data transfer will cost you as follows: $1.00 for the US gets, $1.20 for the Europe gets, $170.00 for each of of the two data transfer volumes (1000 GB each), total $342.20. "No minimum, no cover", no fixed fees, just pay as you go: if next month your volumes double, so will your costs -- if they halve, so will your costs (lower per-GB tariffs only trigger at very high volumes).
In addition, you do have to pay S3 fees as well, since CloudFront edge servers get your data from S3; for the typical case, storage fees will be pennies (your 2000 GB served probably mean just a few GB stored, being served over and over), GET and transfer costs similar to the CloudFront pricing -- however, you typically won't be paying the S3 to edge transfer costs all that often, only when the "cache" kept at the edge nodes needs to be refreshed (so the extra cost depends essentially on the rate of "churn" of your contents).
A very complete article showing all that's needed to use S3 and CloudFront for a simple Ruby on Rails appliation is here -- don't be daunted if you don't do Ruby, it should be simple enough to follow anyway (hey, I don't do Ruby either, but I could follow along;-).
A content delivery network will be anything but "inexpensive". You will need a server in Europe with good connectivity all around. My take would be a UK VPS with 478east, but i'm biased, since i'm with them right now.
Silverlight is a technology, not a content delivery network. Akamai will run you out of house and home unless you're planning to deliver 10TB per month, and can jump into a one year contract.
You haven't mentioned if you will deliver static or streaming content, as that counts, since you might have a harder time using a VPS/server in Europe as you will need to setup a lot more stuff for streaming as opposed to static/progressive streaming.
If you're still in the market, you should look at Aryaka. Their architecture for delivering application seems quite different than traditional CDN. Aryaka's architecture allows for private middlemile transport without ISP peering and TCP op. I hope this helps.
Related
We are planning to host wowza media server with 55 $ monthly charges and take aws instance m1.large along with cloud front support. Use case is we are planning HTTP streaming ( in rare cases RTMP too ). But before going ahead we are not able to concur on costing as it involves multiple variables.
Say we want to stream video of 360p for 400 users every day for 8 hours ( all concurrent) for a month is it going to support & if yes what would be cost?This is classroom scenario where tutor is delivering lecture to students.
If change it 240p and 720p how much cost would vary ?
Would appreciate if we get exact cost for server+ bandwidth estimates(data flow though data is going to be in same region for AWS) ( considering standard encoding)?
Yes, unfortunately multiple variables are involved. First, you need to know what bitrate your video is (240p and 720p don't specify bitrates). The choice of server you make will also affect your pricing, not to mention your maximum concurrent bandwidth.
The Wowza Forums are a good place to look for discussions about server configurations and throughput. AWS has all the pricing for the different servers, as well as pricing for CloudFront.
I'd suggest starting with calculating your min/max bandwidth requirements, then use that to look at your server choices. Then, factor in your CloudFront costs based on usage. And don't forget storage if needed- either an S3 bucket or some EBS volumes on your Wowza server.
The AWS cost calculator might be of some help, too.
I already used Google Compute instance, and it's located us-central.
I'm living Taiwan, ping the instance than average time 180~210ms.
Amazon EC2 located Singapore, average time 70~80ms.
I think this difference latency result, depend your server located, right?
So I guessed Google Compute Engine doesn't support CDN, right?
even Amazon ec2 also the same.
Kind Regards,
PinLiang
Google Compute runs code while a CDN delivers content (**C**ontent **D**elivery **N**etwork) so they aren't the same thing. If you get better latency to Amazon EC2 then use that instead but be aware that Google Compute and EC2 work very differently and you wont be able to run the same code on both.
If you want low latency (to Taiwan) compute resources you might want to consider using a Compute Engine instances in the Asia zones, see: 4/14/2014 - Google Cloud Platform expands to Asia
Yes, location and network connectivity will determine your latency. This is not always obvious though. Submarine cables tend to take particular paths. In some cases a geographically closer location may have higher latency.
A CDN is generally used for distributing static files, at lower latency to more users. Cloudfront can use any site as a custom origin.
I'm in the planning stages of estimating server costs for my web application. How can I determine how many Amazon EC2 instances will I need to handle a database backed web application with 1M active users? How should I go about filling out this monthly calculator on Amazon's site?
http://calculator.s3.amazonaws.com/calc5.html
The web application will be somewhat akin to a social networking site. There will be most likely small, but anywhere from 100,000 to 500,000 data transfers from users to the servers on a daily basis.
To get an accurate estimate of your costs, you will have understand the application architecture, usage patterns and how many servers (instances) and storage and data transfer you expect to use.
Take a look at this video: https://www.youtube.com/watch?v=PsEX3W6lHN4&list=PLhr1KZpdzukcAtqFF32cjGUNNT5GOzKQ8 This video might help you understand how to use the calculator and fill up different values in it.
Jin
Capacity planning is yours, it's specific to app so nobody including Amazon can suggest anything on that regards. Regarding cost estimation, yes you can use monthly calculator. Only thing I could suggest is that when you do your capacity planning make sure that you do your homework like which AWS service you are going to use. For each service you might want to find out unit of measure used for pricing. Once you know that you should do your capacity planning accordingly to find out how much you are projecting to use for a given UOM of a given service on monthly basis. One exception to that is, as you can reserve instances for 3-5 years with upfront fees so you might want to spread that cost across 3 or 5 years based on your choice.
I'm new to everything that is 'the cloud.'
I will be developing a website/platform that will have around 15,000,000 estimated monthly visitors after the first year of production.
I'm assuming that the site will have 5 page views per visitor, and 100kb of data transfer per page.
I've contacted several cloud hosting companies, but they tell me that I need to have 'hardware requirements.'
Since I'm rather clueless about IT stuff, I'd like to know:
What are the factors that need to be analyzed in order to determine
How many servers are required
VPUs / server required
RAM / server required
Total storage / server required
Big thanks in advance!
I don't agree with the other answer as it's nearly total guesswork, as will anything you can generate yourself.
The only surefire way to know is to get some hardware, stick your application on it and run some load testing to see if you can get to the point you want to traffic wise, and with a certain amount of free overhead on the servers. Only then will you know what you need. No-one else can answer this question as every application is different. This is your application, only you can test it.
Data given wont help much in determining what numbers you want. But based on my experience I'll try to help you in analysis.
15,000,000 visits a month means 700K visits a day (assuming approx 30-35% visits are by repeat visitors).
700Kx5=3.5million page views a day.
Assuming 14 hours of active period, typical for single timezeone sites. Its 70reqs/sec.
With this big userbase few thing you surely need is a high performance DB server, with one slave.
Config of these DB server
Memory so that whole active data + indexes fits in memory (No swapping/thrashing should happen). This you need to calculate based on
what you will be storing for user and for how long.
Use some reliable storage like RAID10 (higher read/write bandwith).
Take enough storage, see that its elastic enough. (like AWS EBS).
Make frontend app server lightweight and horizontally scalable. Put them behind a loadbalancer (use software loadbalancer like nginx or HAproxy). You should be able to put as many as you go to your goal.
For loadbalacer and frontend take 4CPU, 4-8GB RAM servers.
How much each frontend can take need to be tested using a load testing method and realistic test data.
Reduce load on database/persistent using a inmemory/+persistent caches like memcached/membase/redis etc. Take a servers with 8GB and add more as you feel need.
I have not discussed about DB partitioning. Do that only when you feel the need of it. Do not over invest at start.
With 15M users a month, this setup should be enough, but again it all depends on you 1. memory footprint, 2. amount of active data
I tried to answer as much as possible. Comments on points you disagree or wanna discuss more.
I have about 15 high res background images for my site, each weigh around 500 MB. Im wondering if there is an advantage to storing them on Amazon S3 instead of my own web server. It seems like the pages should load faster if local to my server, but not sure
My experience with S3 is that it may not be fast because there is a latency that is significant. But the main advantage is that is supposed to be constant and reliable, something that probably you cannot say about a private hosting.
If you decide to use S3, one important detail is choosing the zone (US-East, US-West, Europe, Asia) according to the location of your users. That may reduce the latency.
And another detail is the pricing ( http://aws.amazon.com/s3/#pricing ). With those prices you'll pay about $ 0,1 for each 2K requests of your 500 Kb backgrounds, which in my opinion is cheap.
500mb each is going to be very slow either way. However, if you must have such huge images, S3 with Cloud Front serving it up is likely faster (not sure about that large of files though). I would do both repeatedly (S3 and local) to measure the difference.
500KB you mean?
What you are describing is called a content delivery network or CDN, offloading images from your own webserver to a CDN can be very worthwhile in the right situations. I run a site where where 50% of our hits and 66% of our bandwidth came from images, and we were saturating our pipe.
Rather than spending the $$ to upgrade our link at the colocation facility, we put all our images on a CDN. Instant reduction in both bandwidth AND CPU load from the web server having to serve up static images. That basically gave us another year of growth before we had to do something else.
Amazon S3 isn't really a CDN, we looked into using it as such and a lot of the feedback I found indicated that the big problem was going to be latency, and since in our use case we had many small images to serve up, latency was a factor. So we went with another CDN, but Amazon CloudFront would have been appropriate for that. In our case the cost per request would have been too much for us.