Traditionally running scientific workloads in AWS provides a diverse toolkit that allows researchers to easily sling data around different time zones, regions, or even globally once the data is inside of the infrastructure sandbox. However, getting data in and out of AWS has historically been more of a challenge. The available resources are still evolving and those pesky laws of physics tend to get in the way. Considering the rise of enterprises utilizing cloud for larger data and compute needs and the complexities that come with it, we thought it would be helpful to offer tips on optimizing ingress and egress transfers.

Within scientific computing there is a massive disconnect from theoretical conversations and the real world of data movement. We recently performed a data transfer to Amazon’s Elastic Compute Cloud using their Import/Export service. The service allows customers to mail in data on physical media which is then placed into a S3 bucket or EBS volume of their choice. As an experiment to compare this transfer to network-based transfer mechanisms like multi-stream upload to S3, we recorded all the time it took to prepare and ship the drive to Amazon.

There were several steps to transfer the 317 GBs of DNA sequence data into EC2:

1. Installed AWS Import/Export command line tools.

2. Created an Import job using AWS command line tools including a manifest and signature.

3. Realized that the drive is an ext3 file system (and mounting ext3 on OS X is non-trivial).

4. Created an Ubuntu virtual machine.

5. Mounted the drive on the Ubuntu VM and wrote the signature file and manifest to the drive.

6. Physically labeled the drive with a transfer ID that was provided by the registration process.

7. Packaged and addressed the drive with a specific address that was to be used for the shipment.

8. Headed to the local FedEx and shipped the drive overnight.

9. Waited….

10. Viewed completed transfer logs.

The next step had us moving the data from S3 to an EC2 instance to use it in a computation run. Direct to EBS snapshot is an option, but due to its higher costs as an image of the drive, the unknowns associated with the newness of the feature, and the constrains to the specific content of the file system, we decided against it.

Table of Shipping and Transport Times:

Here is a summary of the entire activity:

This import job was compared to the results on some recent multi-stream upload tests performed with an envy-inducing 5 Mbps upload speed compared to 1 Mbps.

We were able to saturate upload bandwidth and ingress at customer sites, which have much higher outbound data rates in the 50 Mbps range. Further, if there’s a bottleneck for delivering data over the wire it’s on the source end and not on the EC2 end of the line.

The results showed that 50 Mbps of upload speed could saturate a company’s network therefore throttling transfer at 70 percent total bandwidth for an outbound rate 35 Mbps. Interestingly, the transfer speed is faster than the Import/Export service. This shows that almost 500 GB could be moved in the same time it took to transfer by shipping the drive. This drive wasn’t filled to capacity and the theoretical Import/Export throughput would use a full drive by extrapolating the time to load 1TB. Loading that extra data would take about 8 more hours and increase the throughput of the Import/Export approach to 58 Mbps. The rate could also increase if the time it takes to prep the drive was reduced.

What we found from our experiment is that the nature of your workflow should be considered when deciding which transfer method to use. If producing a constant flow of data at a rate that matches the allotted upload bandwidth, streaming over the network is a better option. On the other hand, if there is a large, pre-existing data set and no time to wait for it to upload consider using Amazon’s Import/Export service.

Initiating a transfer entirely in software and having the data eventually make its way into the cloud without getting up from your desk is not always practical. For example, a 317 GB payload would take approximately 30 hours to transfer to AWS if using the Import/Export job approach and 30 days to import 1 Mbps uplink was saturated 24/7. Given a typical enterprise uplink of 50 Mbps, the tables would be turned. Let’s not forget non-technical factors involved in the use of the Import/Export approach such as the hassle handling USB drives, cardboard, packing tape, and cranky shipping depot employees.

Lastly, if the over-the-wire transfer is projected to take longer than a business week, use an AWS Import/Export job instead. AWS Import/Export is an extremely viable way of managing the ingress and egress of data until bandwidth becomes more ubiquitous and plentiful.

Editor’s Note: The original byline was incorrectly attributed to Cycle Computing CEO Jason Stowe.