AWS Transfer Family入門｜オンプレSFTPサーバーをS3に移行するファイル転送基盤の設計と料金ガイド

「社内のSFTPサーバーをそろそろクラウドに移行したい。でも、どのサービスを使えばいいんだろう？」

オンプレ環境でSFTPサーバーを何年も運用してきたエンジニアなら、一度はこの問いに突き当たるはずです。OS保守・ユーザー管理・ディスク増設・HA構成……管理コストは地味に積み重なっていきます。

この記事では、AWSが提供するフルマネージドのファイル転送サービス AWS Transfer Family について、オンプレSFTPサーバーとの比較を軸に解説します。対応プロトコルの整理から、コンソールでの設定手順、料金試算、実務でハマりやすいポイントまでカバーします。

オンプレSFTPサーバーの運用コストを正直に数えてみる

「SFTPサーバーはとっくに安定してるから放っておける」と思っていると、気づいたときには技術的負債が積み上がっています。実際に運用コストを整理すると、次のような手間が隠れています。

・OS保守: セキュリティパッチの適用、OpenSSHのバージョン管理
・ユーザー管理: SSHキーのローテーション、退職者アカウントの棚卸
・ディスク管理: 受信ファイルの増加に伴うディスク拡張、古いファイルの削除ポリシー
・HA構成: Active/Standby構成の場合、フェイルオーバーの仕組みを自分で作る必要がある
・監視: ディスク使用率・接続数・転送失敗アラートを自前で組む必要がある

特に「接続元のパートナー企業が増えるたびに設定変更が発生する」という状況は、運用担当者にとって大きな負担です。AWS Transfer Familyに移行すると、これらの多くをAWSが担ってくれます。

AWS Transfer Familyとは何か

AWS Transfer Familyは、SFTP・FTPS・FTP・AS2の4プロトコルに対応したフルマネージドのファイル転送サービスです。バックエンドのストレージとしてAmazon S3またはAmazon EFSを使うため、受信したファイルがそのままS3バケットに保存されます。

オンプレと比べたときの最大の変化は、「サーバーのOS管理が不要になる」という点です。AWSがサーバープロセスの死活監視・パッチ適用・スケールアウトを自動で行います。

対応プロトコルと用途の整理

1台のTransfer Familyサーバーで複数プロトコルを同時に有効にすることはできません。プロトコルごとにサーバーを作る構成になります。ただし、SFTPとFTPSを同一サーバーで有効化することは可能です。

バックエンドストレージの選択

・Amazon S3バックエンド: 受信ファイルがS3オブジェクトとして保存される。ファイル到着をトリガーにLambda処理を起動するパターンと相性がよく、容量上限もなくコストが低い
・Amazon EFSバックエンド: NFS（ネットワークファイルシステム）として提供されるため、SFTPで受け取ったファイルをEC2上のアプリからそのまま参照できる。レガシーアプリのファイルパスをそのまま活かしたいケースに向く

多くのケースではS3バックエンドが推奨です。EFSバックエンドはEC2上のアプリとファイルパスを共有する必要があるときに限定して使うと費用対効果が高くなります。S3の詳細についてはAmazon S3入門も参照してください。

アーキテクチャの全体像

AWS Transfer Familyの構成を理解するうえで重要なのが「エンドポイントタイプ」と「IDプロバイダー」の2つの概念です。

エンドポイントタイプ：パブリック vs VPC

・パブリックエンドポイント: AWSが管理するパブリックIPを使う。Elastic IPを関連付けることで、接続元パートナーへのIPホワイトリスト提供が可能。インターネット越しのパートナー接続に使う
・VPCエンドポイント: VPC内にエンドポイントを配置。AWS Direct ConnectやSite-to-Site VPN経由のオンプレ接続、またはVPC内の他サービスからの接続に使う。FTPプロトコルを使う場合はVPCエンドポイントが必須

インターネット越しのパートナーと接続するならパブリックエンドポイント、社内閉域のファイル転送やオンプレ連携ならVPCエンドポイントという選択が基本です。

IDプロバイダー（ユーザー認証の仕組み）

Transfer Familyのユーザー認証には3つの方式があります。

・サービスマネージド: AWSコンソール上でユーザーと公開鍵（またはパスワード）を直接登録する。小規模・シンプル構成向け
・カスタムIDプロバイダー（Lambda）: Lambda関数を経由して、既存の社内認証システム（LDAPやActive Directory等）と連携できる。大規模ユーザー管理や既存の認証基盤を流用したいときに有効
・AWS Directory Service: Microsoft Active Directoryとの連携。ADアカウントでSFTPログインを実現

まず試す場合は「サービスマネージド」が最もシンプルです。既存のADと接続する必要があれば「Directory Service連携」を選びます。

コンソールでSFTPサーバーを立ち上げる手順

ここでは、S3バックエンド＋パブリックエンドポイント＋サービスマネージドIDプロバイダーという最もシンプルな構成を例に、手順を説明します。

1. サーバーの作成

AWSコンソールの「AWS Transfer Family」を開き、「サーバーの作成」をクリックします。

・プロトコル: 「SFTP」にチェック（複数プロトコルも選択可）
・IDプロバイダー: 「サービスマネージド」を選択
・エンドポイントタイプ: 「パブリック」を選択
・ドメイン: 「Amazon S3」を選択
・ログ記録ロール: CloudWatch Logsへの出力ロールを新規作成またはアタッチ

「サーバーを作成」すると、数秒でサーバーが立ち上がり、エンドポイントのホスト名（例: s-xxxxxxxx.server.transfer.ap-northeast-1.amazonaws.com）が発行されます。

2. ユーザーの追加

作成したサーバーに「ユーザーの追加」を行います。

・ユーザー名: SFTPログイン時のユーザー名
・IAMロール: このユーザーがS3へのアクセスに使うIAMロールを指定。S3バケットの読み書き権限をアタッチしておく
・ホームディレクトリ: 「制限付き」を選ぶと、ユーザーは自分のホームディレクトリ配下しか見えなくなる（Chrootのような動作）。/bucket-name/home/username のように設定する
・SSHパブリックキー: ssh-keygenで生成した公開鍵を貼り付ける（パスワード認証を有効化することも可）

IAMロールの設計では最小権限が重要です。対象バケット・プレフィックスに限定したポリシーを付与しましょう。

3. SFTPクライアントから接続テスト

手元のSFTPクライアント（WinSCP、FileZilla、またはコマンドライン）から接続確認します。

# コマンドラインから接続テスト（SFTPの標準ポート22番を使用）
sftp -i ~/.ssh/your-private-key username@s-xxxxxxxx.server.transfer.ap-northeast-1.amazonaws.com

# 接続成功後、ファイルをアップロードしてS3に届くことを確認
sftp> put testfile.csv
Uploading testfile.csv to /testfile.csv
testfile.csv                                  100%  2048     2.0KB/s   00:00

AWSコンソールのS3バケットを確認し、ファイルが届いていれば設定は完了です。

料金の仕組みとコスト試算

AWS Transfer Familyの料金は大きく「エンドポイント（サーバー）の稼働時間」と「データ転送量」の2本立てです（2026年7月時点・東京リージョン ap-northeast-1）。

※ 料金は執筆時点のものです。最新料金はAWS公式の料金ページでご確認ください。

【試算例】24時間365日稼働のSFTPサーバー1台

・エンドポイント料金: $0.30 × 24時間 × 30日 = 月額約$216
・データ転送料金（月500GBアップロードの場合）: $0.04 × 500GB = 月額約$20
・S3ストレージ（累積100GBの場合）: 約$2.5/月
・合計目安: 月額約$238（約3.6万円）

オンプレのSFTPサーバーを維持するコスト（サーバーハードウェアの減価償却・電力・ラック費用・OSライセンス・管理工数）と比べてどちらが安いかは環境によりますが、管理工数の削減効果はほぼ確実に得られます。

コストを抑える設計パターン

・バッチ受信限定運用: 日次バッチでのみファイルを受信するなら、受信時間帯だけサーバーを起動してAWS CLIで停止することで、月の稼働時間を大幅に削減できる（例: 1日2時間稼働なら月$18程度）
・S3ライフサイクルルールの活用: 処理済みのファイルをGlacierへ移動することでストレージ料金を抑える
・プロトコルの絞り込み: 実際に使うプロトコルだけ有効化する（SFTPとFTPSを両方有効にすると課金が加算される）

実務で役立つ設計Tips

S3バケット設計：ユーザー別プレフィックスの分離

複数パートナーがファイルを受け渡す場合、S3バケット上のプレフィックスでユーザーを分離するのがベストプラクティスです。各ユーザーのIAMロールに、自分のプレフィックス配下のみ読み書きできるポリシーをアタッチします。

# パートナーA向けIAMロールのポリシー例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-transfer-bucket",
      "Condition": {
        "StringLike": {"s3:prefix": ["home/partner-a/*"]}
      }
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::my-transfer-bucket/home/partner-a/*"
    }
  ]
}

この構成にすることで、パートナーAは自分の領域（/home/partner-a/）しか参照できなくなります。パートナーが増えてもバケットは1つのまま管理できます。

ファイル到着をトリガーにした後続処理の自動化

S3バックエンドを使う最大のメリットは、S3イベント通知と組み合わせて後続処理を自動化できる点です。

・S3バケットのイベント通知（s3:ObjectCreated:*）→ Lambda関数を起動 → ファイルを検証・変換・後段DBへインサート
・Amazon EventBridgeルールでS3への書き込みを検知し、AWS Step Functionsのワークフローを起動

この流れを使うと「SFTPで受け取ったCSVを自動で取り込む」というパイプラインが、コード管理可能な形で構築できます。これはオンプレのSFTPサーバーではinotifyやポーリングで実現していたことを、イベント駆動に置き換えるイメージです。

CloudWatchでの転送ログ監視

サーバー作成時にCloudWatch Logsへのログ記録ロールを設定しておくと、転送ログ（接続ユーザー名・転送ファイル名・バイト数・エラー）がCloudWatch Logsに書き込まれます。Amazon CloudWatchでアラートを設定しておくと、特定ファイルの未着（時刻監視）や転送失敗の自動通知が実現できます。

S3サーバーサイド暗号化との組み合わせ

受信ファイルが個人情報や機密データを含む場合、S3バケットのデフォルト暗号化をAWS KMS（SSE-KMS）で有効にしておくことを推奨します。AWS KMSのカスタムキーを指定すれば、鍵のアクセスログ（CloudTrail）も取得できます。Transfer FamilyからのS3書き込みはバケットのデフォルト暗号化ポリシーに従うため、Transfer Family側の追加設定は不要です。

Elastic IPでIPアドレスを固定する

パートナー企業から「接続先IPを固定してほしい」という要望は珍しくありません。パブリックエンドポイント使用時にElastic IPを割り当てることで、サーバーを再起動してもIPアドレスが変わらない構成にできます。VPCエンドポイント使用時は、Network Load Balancer（NLB）経由でElastic IPを割り当てる構成が必要になります。

AWS Secrets Managerとの連携（カスタムIDプロバイダー使用時）

カスタムIDプロバイダー（Lambda）を使ってパスワード認証を実装する場合、ユーザーパスワードをAWS Secrets Managerに格納し、Lambda認証関数からSecrets Managerを参照する構成がベストプラクティスです。パスワードをLambdaコードやDynamoDBにハードコードする構成は避けましょう。

よくあるトラブルと対処法

1. 「Permission denied」で接続が切断される

原因: SSHキーの不一致、またはIAMロールの権限不足（S3へのPutObjectが許可されていない）。

対処: まずAWSコンソールでユーザーに登録した公開鍵とクライアントの秘密鍵が対応しているか確認します。次に、IAMロールにアタッチされたポリシーで s3:PutObject と s3:ListBucket が付与されているか確認してください。CloudTrailのログを見ると、S3へのAPIコールが拒否されているかどうかがすぐわかります。

2. ログインできるが、ファイルが一覧に出ない

原因: ホームディレクトリの「制限付き」設定で、パスの設定を間違えている。

対処: AWSコンソールでユーザーのホームディレクトリマッピングを確認します。「論理ディレクトリマッピング」を使っている場合、マッピングエントリの「ターゲット」が実際のS3プレフィックスと一致しているか確認します。S3コンソールで直接そのプレフィックス配下を確認して、ファイルが存在しているかチェックするのが確実です。

3. 大きなファイルの転送が途中で切断される

原因: SFTPクライアント側のタイムアウトまたはネットワーク不安定。Transfer Family自体に最大ファイルサイズ制限はありません（S3のマルチパートアップロード上限まで対応）。

対処: WinSCPなどのクライアントでは「KeepAlive」設定を有効にします。コマンドラインsftpの場合、-o ServerAliveInterval=60 オプションを付けて定期的なキープアライブを送信することで安定します。

4. CloudWatch Logsにログが出力されない

原因: サーバーに設定した「ログ記録ロール」のIAMポリシーが不足している。

対処: ログ記録ロールに logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents の3つの権限があるか確認します。AWSマネージドポリシー「AWSTransferLoggingAccess」をアタッチするのが最も確実な方法です。

5. FTPクライアントでパッシブモードが繋がらない

原因: FTPSのパッシブモードはデータポートが動的に決まるため、ファイアウォールやセキュリティグループの設定が追いついていない。

対処: VPCエンドポイント使用時は、セキュリティグループでポート8192～8200（Transfer FamilyのFTPSパッシブポート範囲）を開放します。パブリックエンドポイントはAWS側が制御するため、クライアント側のファイアウォール設定を確認します。

本記事のまとめ

AWS Transfer Familyは「SFTPサーバーをそのままAWSに持っていける」という単純な置き換えサービスではなく、S3をバックエンドにすることでファイル受信後の処理を大幅に自動化できる点が本質的な価値です。まずはサービスマネージドIDプロバイダーとS3バックエンドの組み合わせでシンプルに試してみて、要件が複雑になればカスタムIDプロバイダーやVPCエンドポイントに拡張する進め方がお勧めです。