AWS Transfer Family

解決する課題

取引先や社内システムとのファイル授受で、いまだに SFTP や FTPS、FTP が使われている現場は数多くあります。これらのプロトコルを受けるには転送サーバーを自分で立て、OS やソフトウェアのパッチを当て、可用性のために冗長化し、ユーザー認証を管理する必要があります。サーバー1台にこれだけの運用が乗ってきます。AWS Transfer Family は、こうした転送サーバーの運用をマネージドサービスとして肩代わりし、受け取ったファイルを直接 S3 や EFS に置けるようにします。

• 既存の取引先が使う SFTP/FTPS/FTP のクライアントをそのまま使わせたい
• 転送サーバーの構築・パッチ適用・冗長化を自前で運用したくない
• 受け取ったファイルをS3 や EFS に直接置き、後続の処理につなげたい
• ユーザーごとの認証とアクセス範囲をきちんと管理したい

主要概念と用語

• サーバー: 転送を受け付けるエンドポイントの単位。対応プロトコル（SFTP/FTPS/FTP）や認証方式、エンドポイントの種類などを設定する
• プロトコル: SFTP（SSH 上のファイル転送）、FTPS（TLS で暗号化した FTP）、FTP（暗号化なし）の3種類。1つのサーバーで複数を有効にできる
• ユーザー: サーバーに接続する利用者の単位。ログイン名、認証情報、アクセスできる保存先の範囲を持つ
• アイデンティティプロバイダー: ユーザーの認証方式。サービス自身が管理する方式のほか、外部ディレクトリやカスタム認証と連携できる
• ホームディレクトリ: ユーザーがログインした際に見えるディレクトリの起点。S3 のバケットやプレフィックス、EFS のパスに対応づける
• エンドポイントの種類: インターネット公開のパブリック、VPC 内に置くタイプなど、サーバーをどこに公開するかの選択
• ワークフロー: アップロード後に実行する一連の処理の定義。ファイルのコピーやタグ付け、関数呼び出しなどを連結できる

仕様・制限・クォータ

• 対応プロトコルは SFTP・FTPS・FTP で、1つのサーバーで複数を有効化できる
• 保存先には S3 と EFS を指定でき、ユーザーごとにアクセスできる範囲を絞れる
• エンドポイントはインターネット公開のほか、VPC 内に配置してプライベートに使う構成も選べる
• 認証はサービス管理、ディレクトリ連携、カスタム認証などから選択できる
• 同時接続数やユーザー数、ワークフローのステップ数などには上限があり、時期やリージョンによって変わりうる

内部の仕組み

利用者はまずサーバーを作成し、受け付けるプロトコルとエンドポイントの種類、認証方式を決めます。次に接続するユーザーを登録し、それぞれのホームディレクトリを S3 や EFS のパスに対応づけます。取引先は手元の SFTP/FTPS/FTP クライアントから、このサーバーのエンドポイントに接続します。

接続時にはアイデンティティプロバイダーで認証が行われ、許可されたユーザーだけがログインできます。ユーザーがファイルをアップロードすると、その実体は対応づけられた S3 や EFS にそのまま保存されます。アップロードをきっかけにワークフローを起動すれば、コピーやタグ付けといった後続処理を自動でつなげられます。サーバー自体の冗長化やスケーリング、パッチ適用はサービス側が受け持つため、利用者は転送サーバーの中身を管理する必要がありません。

設計パターン / ベストプラクティス

• 取引先とのファイル交換: 既存の SFTP クライアントを維持したまま、受け取ったファイルを S3 に集約し、後続のデータ処理につなぐ
• アップロード起点の自動処理: ワークフローでアップロード後にタグ付けや配置、関数呼び出しを行い、手作業を挟まずに処理を流す
• ユーザーごとのアクセス分離: ホームディレクトリと IAM を組み合わせ、各ユーザーが自分の領域だけを読み書きできるようにする
• プライベート公開: 社内や閉域からのみ使う場合は VPC 内エンドポイントにし、インターネットへ露出させない
• 既存ディレクトリとの統合: 認証を外部ディレクトリやカスタム認証に寄せ、ユーザー管理を一元化する
• 暗号化プロトコルの徹底: 外部公開のエンドポイントでは SFTP か FTPS を使い、平文の FTP を避ける

運用・監視

• 接続や転送の記録を CloudWatch のメトリクスやログで監視し、失敗や異常なアクセスを検知する
• ユーザーごとのログイン成否や転送状況を確認し、想定外の接続元や失敗の急増がないかを把握する
• ワークフローを使う場合は、各ステップの成功・失敗を確認し、後続処理が正しく流れているかをチェックする
• 認証方式にカスタム認証や外部ディレクトリを使う構成では、その連携先の可用性も含めて監視する
• エンドポイントの種類や対応プロトコルの設定変更が、取引先の接続に影響しないよう事前に確認する

コスト

• 課金は主に、サーバーのプロトコル有効化に対する時間あたりの料金と、転送したデータ量に応じた従量制で構成される
• 複数プロトコルを1つのサーバーで有効化すると、そのぶんだけ時間あたりの費用がかかる点に注意する
• 保存先が S3 や EFS のため、保存にかかる費用は保存先ストレージ側の料金に従う
• 使わないサーバーは停止・削除しておくと、待機状態でも発生しうる時間課金を抑えられる

セキュリティ

• SFTP と FTPS では転送中のデータが暗号化される。FTP は平文のため、用途と経路を限定する
• 認証はサービス管理・ディレクトリ連携・カスタム認証から選び、要件に合わせて方式を決める
• 保存先への権限は IAM で制御し、ユーザーが自分のホームディレクトリの範囲だけを読み書きできるよう最小権限に絞る
• 保存時の暗号化は、保存先となる S3 や EFS 側の KMS 連携に従う
• インターネットに露出させたくない場合は VPC 内エンドポイントにし、接続元を限定する

Well-Architected の観点

• セキュリティ: SFTP/FTPS による転送中の暗号化、IAM とホームディレクトリによるユーザー単位のアクセス分離、VPC 内エンドポイントによる接続元の限定
• 運用上の優秀性: 転送サーバーの構築・パッチ適用・冗長化をサービスが肩代わりし、運用負荷を下げる。ワークフローでアップロード後の処理を自動化できる
• 信頼性: サーバーの可用性とスケーリングをマネージドに任せられ、転送基盤を自前で冗長化する必要がない
• コスト最適化: 不要なプロトコルを有効化しない、使わないサーバーを止めるといった調整で時間課金を抑える

試験で問われるポイント

関連サービス・比較

データ移行サービスの AWS DataSync とよく対比されます。Transfer Family は標準プロトコルでファイルを受け渡しする受け口、DataSync は大量データを高速に転送・同期する移行という役割の違いを押さえます。

ハンズオン / CLI例

# SFTP を有効にしたサーバーを作成（サービス管理の認証を使う例）
aws transfer create-server \
  --protocols SFTP \
  --identity-provider-type SERVICE_MANAGED \
  --endpoint-type PUBLIC

# 作成済みサーバーの一覧を確認
aws transfer list-servers

# サーバーにユーザーを追加し、S3 のホームディレクトリと IAM ロールを対応づける
aws transfer create-user \
  --server-id s-XXXXXXXXXXXXXXXXX \
  --user-name partner01 \
  --role arn:aws:iam::123456789012:role/transfer-access-role \
  --home-directory /example-bucket/partner01

# ユーザーの設定内容を確認
aws transfer describe-user \
  --server-id s-XXXXXXXXXXXXXXXXX \
  --user-name partner01