Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am setting up a new EC2 instance. As part of this, I need to move a large file (100GB) up to EC2 from our colo data center. (E.g. the colo site has lots of bandwidth....).

My EC2 instance has a large EBS volume, so I have a place to put it.

I tried robocopy, but that was taking forever. Now I am trying teracopy, but this appears it will take 12 hours. (it is clocking 1.8MB/s right now) (Both robocopy and teracopy work using Windows file shares.)

  • Colo data center: Lots and lots of bandwidth (30-60mbps outbound or more)
  • EC2 instance: m1.medium instance

What are the options for moving this faster?

Thank you!

share|improve this question
What size AWS instance? Bigger ones get more bandwidth. How big's the pipe on your end? – ceejayoz Sep 16 '13 at 16:46
@ceejayoz OP revised – samsmith Sep 16 '13 at 17:03
are you doing this over a windows file share? – Matt Sep 16 '13 at 18:03
60mbps - megabit. You call that lots and lots of bandwidth? Seriously? Like 1990? 1gigabit would be good today. Your data center should facilitate fast copy operations. – TomTom Sep 16 '13 at 18:58
That is 60 megabits of actual, available, bandwidth ... not 1 megabit. Full gigabit is rarely seen all the way out of the data center to the wild, as there are other traffic generators, usually on both ends. – samsmith Sep 16 '13 at 19:18

My first move would be trying a much larger instance. m1.mediums have "moderate" network performance.

Something like the hi1.4xlarge would give you a 10 gigabit connection to AWS's network. If testing with one doesn't show better performance, the bottleneck isn't AWS.

share|improve this answer
Thanks, I see what you refer to. Seems like I almost want a direct connection from "outside" AWS to EBS just to push data. Then connect the EBS volume to whatever instance..... (rather than having to go through an instance to EBS) – samsmith Sep 16 '13 at 17:43
Yep. Make your EBS volume on a huge instance, then attach it to a more normally sized instance later. You'll pay a few bucks for the transfer but it'll be dramatically faster. – ceejayoz Sep 16 '13 at 17:44
Those refer to LAN network speeds which will generally be well in excess of net bandwidth. I can pull 6-10MB/s down to a t1.micro instance off the internet. See… – Matt Sep 16 '13 at 19:02
OK, spun up an xlarge.... and not seeing any faster perf. This may mean the bottleneck is elsewhere (but, as I have never seen xlarge be faster, it does not help indicate where the bottleneck is). – samsmith Sep 16 '13 at 21:26
Using both SMB1 (file share) and ftp, I found identical throughput to medium and xlarge instances from the cloud. – samsmith Sep 16 '13 at 23:02

You can test the Amazon link and EBS volume by downloading something off a large mirror site in the same geographical region as your instance. My t1.micro instance in the EU can get ~6-9MB/s from In US-West on a micro I can get 2-4MB/s from

Try doing your transfer with something like FTP/SCP/SFTP which might be a bit quicker than CIFS over a WAN link, especially if you have an older version of Windows at either end.

If there is anything else going out the colo link, 1.8 MB isn't that far from the bandwidth you quoted. You might be able to eek some more out of the link by splitting the file into chunks and running the copy for each chunk in parallel. ymmv depending on what is limiting the bandwidth.

share|improve this answer

Alternately, you can snail-mail your data:

share|improve this answer
up vote 2 down vote accepted


Issue looks to be as follows: robocopy and teracopy are going over file share. And.... since the servers are win2003 on one side and win2012 on the other, we are stuck on SMB1 which is not ideal for WAN transfers like this. (If both sides were Win2008 or higher, SMB2 would be auto negotiated, which is allegedly ideal for transfers like this.)

So we fired up ftp instead, using filezilla as the ftp server and filezilla ftp client. Annnnnnnnnnnd.... the results are in:

  • 3-4 hour estimated transfer time
  • 6.4MB/s

This is up from the robocopy / teracopy results which were

  • 12 hours
  • 1.8MB/s

We tested both the robocopy / teracopy and ftp solutions against both EC2 medium and xlarge instances and saw no difference at all in throughput based on the EC2 instance type. The only difference was in the protocol used to move data. (If there is a delta in throughput in "from the cloud" traffic, the bottleneck is somewhere I can't see.)

share|improve this answer
It's possible that using CIFS/SMB was causing it to use sync writes rather than async, therefore it was waiting for a response after each filesystem block write instead of queuing up a lot at once. FTP transfers work as a stream so it doesn't employ the concept of writing filesystem blocks one by one. – Paccc Sep 18 '13 at 18:43

Move it via S3.

It's almost 2 years later, and EC2 network performance in and out is still not great. It is actually faster to move via S3 even though this is an extra hop. I am in Sydney.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.