回答:
3つのオプションがあります。
Amazon AWSコンソールで、AWS Transfer for SFTPに移動し、新しいサーバーを作成します。
SFTPサーバーページで、新しいSFTPユーザーを追加します。
ユーザーのアクセス許可は、IAMサービスの関連するAWSロールによって管理されます（クイックスタートでは、AmazonS3FullAccessポリシーを使用できます）。
ロールには、との信頼関係が必要transfer.amazonaws.comです。
詳細については、私のガイド「Amazon S3へのSFTPアクセスのセットアップ」を参照してください。
s3fsファイルシステム（または同様のもの）を使用してバケットをLinuxサーバー（Amazon EC2など）にマウントし、サーバーの組み込みSFTPサーバーを使用してバケットにアクセスするだけです。
s3fsaccess-key-id:secret-access-keyに追加して/etc/passwd-s3fsバケット取り付けエントリをに追加しますfstab。
<bucket> /mnt/<bucket> fuse.s3fs rw,nosuid,nodev,allow_other 0 0
詳細については、私のガイド「Amazon S3へのSFTPアクセスのセットアップ」を参照してください。
または、無料の「FTP / SFTPクライアント」を使用します。これは「S3クライアント」でもあり、サーバー側で何もセットアップしていません。たとえば、私の WinSCPやCyberduckです。
転送を自動化する必要がある場合、WinSCPにはスクリプトと.NET / PowerShellインターフェースさえあります。
root後で転送のpermission denied問題が生じec2-userます。/mnt/<bucket>フォルダはによって所有されroot、グループrootも持っています。
allow_other（または-o allow_others3fsコマンドラインからマウントする場合）でマウントされていることを確認します。私の場合（プライベートバケット上）、ファイルを読み取り専用アクセス許可（-o default_acl = public-read）として書き込むこともお勧めします。
更新
S3は、IAMと統合し、aws-cliを使用して管理できるS3向けのフルマネージドSFTPゲートウェイサービスを提供するようになりました。
これが完全な解決策ではない理由には理論的および実用的な理由がありますが、機能します...
LinuxサーバーにEC2または独自のデータセンターでFTP / SFTPサービス（proftpdなど）をインストールできます。次に、s3fsを使用して、FTPサーバーがchrootに設定されているファイルシステムにバケットをマウントします。
私はS3からコンテンツを提供するクライアントがあり、コンテンツはFTPプッシュのみをサポートするサードパーティによって提供されています...そのため、（S3と実際のファイルシステム間のインピーダンスの不一致のため）ためらいがありますが、適切なFTP / S3ゲートウェイサーバーソフトウェアパッケージを作成する時期（私は今でもそのうちの1つを行うつもりです）に、このソリューションを数か月前に提案して展開しましたが、システムに関する問題は報告されていません。
おまけとして、proftpdは各ユーザーを自分のホームディレクトリにchrootし、proftpdユーザーが所有するファイルが実際にはログインしたユーザーが所有していると（ユーザーが知る限り）「偽装」できるため、これにより各ftpユーザーがバケットの「サブディレクトリ」。他のユーザーのファイルにアクセスできなくなります。
ただし、デフォルトの構成には問題があります。
数十または数百のファイルの取得を開始すると、ディレクトリリストをプルしたときに問題が発生します。これは、ProFTPdが.ftpaccessファイルを何度も何度も、またディレクトリ内のファイルごとに読み取ろうとするためです。.ftpaccessユーザーに表示を許可する必要があるかどうかを確認するためにチェックされます。
この動作はProFTPdで無効にすることができますが、最も正しい構成は-o enable_noobj_cache -o stat_cache_expire=30s3fsで追加のオプションを構成することです。
-o stat_cache_expire（デフォルトは有効期限なし）統計キャッシュ内のエントリの有効期限（秒）を指定する
このオプションを使用しない場合、S3へのリクエストが少なくなりますが、s3fsの外部プロセスまたは他のインスタンスもバケット内のオブジェクトを変更している場合、オブジェクトに加えられた変更を常に確実に検出できるとは限りません。私のシステムの値「30」は、いくぶん恣意的に選択されました。
-o enable_noobj_cache（デフォルトは無効）存在しないオブジェクトのキャッシュエントリを有効にします。s3fsが何らかのコマンドを実行するとき、s3fsは常にオブジェクト（パス）にファイル（またはサブディレクトリ）が存在するかどうかを確認する必要があります。ListBucketリクエストが増加し、パフォーマンスが低下します。パフォーマンスのためにこのオプションを指定できます。s3fsは、オブジェクト（ファイルまたはディレクトリ）が存在しないことをstatキャッシュに記憶します。
このオプションにより、s3fs .ftpaccessはそこになかったことを思い出すことができます。
上記の変更によって解決される、ProFTPdで発生する可能性のあるパフォーマンスの問題とは無関係に、s3fsでも有効-o enable_content_md5にする必要があります。
-o enable_content_md5（デフォルトは無効）content-md5ヘッダーによって、マルチパートなしでアップロードされたデータを検証します。マルチパート投稿なしでオブジェクトをアップロードするときに「Content-MD5」ヘッダーを送信できるようにします。このオプションを有効にすると、小さいオブジェクトをアップロードするときのs3fsのパフォーマンスに影響します。ラージオブジェクトをアップロードする場合、s3fsは常にMD5をチェックするため、このオプションはラージオブジェクトには影響しません。
これはオプションであってはならないオプションです。これを実行しないと、パフォーマンス上の利点が無視できるほど重要な整合性チェックがバイパスされるため、常に有効にする必要があります。オブジェクトがContent-MD5:ヘッダー付きでS3にアップロードされると、S3はチェックサムを検証し、転送中に破損している場合はオブジェクトを拒否します。可能性は低いですが、この安全性チェックを無効にするのは近視眼的です。
引用はs3fsのmanページからのものです。文法上の誤りは元のテキストにあります。
sudo s3fs bucket-name /local-mount-folder-name/ -o iam_role=sftp-server -o allow_other -o umask=022 -o uid=501 -o gid=501-作成されたMounted S3フォルダー内のフォルダーに対するアクセス許可を変更することはできません。
私に反対票を投じている人々のための2014年からの回答：
まあ、S3はFTPではありません。ただし、S3をサポートするクライアントはたくさんあります。
TransmitやCyberduckなど、OS Xのほとんどすべての注目すべきFTPクライアントがサポートしています。
Windowsを使用している場合は、CyberduckまたはCloudBerryをご覧ください。
2019の回答の更新：
AWSは最近、AWS Transfer for SFTPサービスをリリースしました。
Filezilla がFTPクライアントのProバージョンをリリースしました。それは経験のような合理化されたFTPでS3バケットに接続します。私はそれを自分で使用し（アフィリエーションはありません）、うまく機能します。
まず、S3アクセス権限を持つAWSユーザーに「アクセスキーID」が作成されていることを確認します。また、「シークレットアクセスキー」を知っている必要があります。アクセスキーは、IAM管理コンソールの[ユーザー]ページで作成および管理されます。
[新しいサイトノード]が選択されていることを確認します。
[新しいサイト]ノードで、[Amazon S3プロトコル]を選択します。
AWSユーザーアクセスキーIDとシークレットアクセスキーを入力します
[保存]ボタンを使用してサイトの設定を保存します。
ログインボタンを使用してログインします。
AmazonはS3用のSFTPサービスをリリースしましたが、それらはSFTPのみを実行し（FTPまたはFTPESは実行しません）、状況によっては法外な費用がかかる可能性があります。
私はDocEvent.ioの創設者です。サーバーを起動したりインフラストラクチャを心配したりすることなく、S3バケットにFTP / Sゲートウェイを提供しています。
ソフトウェア構成を介してS3バケットに接続できる月単位で支払うスタンドアロンFTPサーバーを提供している他の会社もあります（例：brickftp.com）。
最後に、役立ついくつかのAWS Marketplaceアプリもあります。ここに検索リンクがあります。これらの多くは独自のインフラストラクチャでインスタンスを起動します。つまり、インスタンスを自分で管理およびアップグレードする必要があり、時間の経過とともに維持および構成することが困難になる可能性があります。
他の投稿者が指摘しているように、AWS Transfer for SFTPサービスにはいくつかの制限があります。要件を厳密に調整する必要があります。たとえば、割り当て、ホワイトリスト/ブラックリスト、ファイルタイプの制限はなく、非キーベースのアクセスには外部サービスが必要です。また、ユーザー管理とIAMに関連する特定のオーバーヘッドがあり、規模が大きくなる場合があります。
お客様のために、SFTP S3プロキシゲートウェイを約5年間実行しています。コアソリューションはDockerサービスのコレクションにラップされ、オンプレミスまたはローカルの開発サーバーであっても、必要なコンテキストに展開されます。私たちのソリューションは、データ処理とパイプラインとファイル共有に重点を置いているため、ユースケースは少し異なります。Salesforceの例では、顧客はメールを送信する転送方法としてSFTPを使用し、購入...データをSFTP / S3エンドポイントに送信します。これは、S3のオブジェクトキーにマップされます。到着すると、データが取得、処理、ルーティングされ、倉庫にロードされます。また、転送ごとにかなり重要な監査要件があり、AWSのCloudwatchログでは直接提供されません。
他の人が述べたように、自分でロールすることもオプションです。AWS Lightsailを使用すると、Route 53またはELBのいずれかを使用して、クラスター、たとえば4、$ 10の2GBインスタンスをセットアップできます。
一般に、AWSがこのサービスを提供しているのは素晴らしいことであり、今後も成熟していくと思います。ただし、ユースケースによっては、代替ソリューションの方が適している場合があります。