一つめのニーズである、大容量のファイルを安価にバックアップするには、シンプルな構成が適する。具体的には、コマンドラインでファイルをクラウドストレージに転送する構成である。
例えばTISの中澤氏がコンテンツ事業者に提案したケースが分かりやすい。オンプレミス側にLinuxベースのファイルサーバーを用意し、AWSのAPIの実行環境を整備。スクリプトを作成して自動的にファイルをクラウドストレージサービスの「Amazon Simple Storage Services（S3）」にアップロードする仕組みにした（図3）。バックアップ専用のハードウエアやソフトウエアを利用しておらず、構築のコストや手間が少なくて済む。
さらに中澤氏は、アーカイブ用途を想定したストレージサービス「Amazon Glacier」の併用を提案した。Glacierはデータの取り出しに追加コストや時間がかかる代わりに、S3の3分の1程度のコストで利用できる（第4回の別掲記事も参照）。
そこで、S3に保存したバックアップのデータを、一定期間経過するとアーカイブ向きのGlacierに自動的に移動させる。構築時だけでなく、運用後のコストも節約するための工夫である。
初回だけ転送用サーバーを活用
実際に構築する際に課題となったのが、初回のバックアップである。これまでオンプレミスで蓄積してきた大容量のデータをすべて、バックアップ用ストレージとして利用するS3に送り込む必要があった。
AWSと接続するインターネットの接続回線のスループットを計測したところ、帯域に余裕があれば毎秒20Mビット出たが、混雑していると同200kビットまで落ち込むケースもあった。最悪のケースで1カ月近い時間がかかる。ユーザー企業の運用開始時期の要望を満たせなかった。
そこでバックアップの初回に限り、別のデータ転送方法を採用した。具体的には、AWSの仮想マシンサービス「Amazon Elastic Compute Cloud（EC2）」を利用して転送用サーバーを稼働させた。一方、オンプレミスでは、ファイルサーバーのディレクトリー単位で、バックアップ対象のデータをひとまとまりのアーカイブファイルにしておく。そして、このアーカイブファイルをFTPを使って転送用サーバーへと送り込む。
FTPは一般に、オンプレミスからS3へのデータ転送で利用するHTTPまたはHTTPSより高速に通信できる。転送用サーバーとS3の間の通信は、同じAWS内のため、オンプレミスから送る場合より高速である。
このようにコマンドラインによるファイル転送は手軽に利用できる半面、バックアップ対象のシステムと運用ポリシーが多岐にわたる場合は注意したい。スクリプトのメンテナンスの負担が重くなりやすいからだ。