AWS DataSync はオンプレから AWS 上の S3 や EFS にデータを転送するものというイメージだったので、それならあまり使う機会はないかなー、と思っていたのですが下記によると EFS と S3 の間でデータの転送もできるので、それなら使う機会もあるかもー、と思って試してみました。
https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/working-with-locations.html
今回は EFS から S3 への転送を試しました、逆でもあまり変わらないと思います。
エージェント
AWS DataSync を利用するためには VMware や EC2 などにエージェントをデプロイする必要があります。エージェントが NFS や SMB でファイルシステムへアクセスしたり、S3 や EFS などの AWS サービスにアクセスしたりします。
エージェントは AMI や仮想マシンのイメージとして提供されてます。そのため仮想マシン全体が DataSync エージェントの専有になります。rpm とかで既存のインスタンスにインストールしたりはできません。
エージェントをデプロイする仮想マシンのスペックの要件はかなり高いです。EC2 インスタンスだと最低でも m5.2xlarge が必要とのことです。
https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/agent-requirements.html#hardware
エージェントのアクティベーション
デプロイしたエージェントを DataSync で利用可能にするためにはエージェントのアクティベーションが必要です。
エージェントはデプロイされた直後は 80 番ポートでリッスンしています。HTTP で開くとアクティベーション用のコードが生成されるので、それを DataSync に入力すればアクティベーションが完了します。
https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/create-agent-cli.html
Terraform を使う場合はこれはあまり気にしなくても良いです。エージェントの IP アドレスだけ指定しておけば Terraform が自動的にアクティベーションしてくれます。ただし Terraform を実行しているホストからエージェントの 80 番ポートへアクセスできる必要があります。
ロケーション
送信元として NFS を、送信先として S3 を、それぞれ DataSync のロケーションとして登録します。
ロケーションの種類には EFS もありますが、これをソースとして S3 への転送はできません。下記の表の通り送信元と送信先のどちらか片方が NFS または SMB である必要があります。
https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/working-with-locations.html
要するに「NFS や SMB などのネットワークファイルシステム」と「EFS や S3 などの AWS サービス」との間で転送ができる、ということですね。
スケジュール
Terraform では今の時点ではまだスケジュールが設定できなかったので、マネジメントコンソールから設定しました。
https://github.com/terraform-providers/terraform-provider-aws/issues/10995
スケジュールは cron 式で設定できます。スケジュールの間隔は最短でも1時間までです。
なお、スケジュールだけではなく、他にもいろいろ Terraform からは設定できませんでした。
- ログレベル（素のままだとログが出力されない）
- PrivateLink のエンドポイントのエージェント（エージェントのインスタンスはパブリックに置くしかない）
アクセス制御
NFS のアクセス制御は、エージェントから nfs マウントできるかどうかだけなので、エージェントおよび EFS マウントターゲットのサブネットマスクやセキュリティグループだけ気にしておけば大丈夫です。
S3 のアクセス制御は、DataSync の S3 のロケーション設定で IAM Role を紐つけます。DataSync はこの IAM Role を使って S3 バケットにアクセスします。エージェントのインスタンスプロファイルじゃないの？ と思いましたが、DataSync エージェントはオンプレにもデプロイできるのでインスタンスプロファイルなわけがありませんね。
ログの書き込みのための CloudWatch Logs へのポリシーもインスタンスプロファイルではなく CloudWatch Logs のリソースポリシーで設定します。
https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/monitor-datasync.html#cloudwatchlogs
CloudWatch Logs のリソースポリシー・・これマネジメントコンソールからは全く見えません。ユーザーガイドにもほとんど説明がないようです。下記で説明されている「リソースベースのポリシー」かと思ったのですが、参照されているAPIから察するにこれは別の物のようです（これは送信先に紐つけるポリシーのようなので）。
下記のよると CloudWatch Logs のリージョンレベルのポリシーのようです（特定のリソースには結びつかない）。
さいごに
試してみたものの・・・DateSync のために結構なサイズのインスタンスを専有にする必要があるので、それなら適当なインスタンスで aws s3 sync で良いのでは、と思いました。
下記によるとコマンドラインツールの10倍早いとのことですが・・実際にある程度の規模のデータで試してみないことにはどちらが良いかわかりませんね。
https://aws.amazon.com/jp/datasync/faqs/#When_to_choose_AWS_DataSync
オンプレの NFS から継続的に S3 などにデータ同期するという目的であればまあ使えると思います。
