AWS Transfer Family のよくある質問

はい。組織ポリシーや利用規約など、カスタマイズしたバナーをユーザーに表示するよう、Transfer Family サーバーを設定することができます。また、認証に成功したユーザーに対して、カスタマイズした本日のメッセージ (MOTD) を表示することも可能です。詳細については、ドキュメントをご覧ください。

はい。このサービスは、エンドポイントにアクセスするためのドメイン名をデフォルトで提供します。ドメイン名を既にお持ちの場合、Amazon Route 53 または任意の DNS サービスを使用して、登録済みのドメインから AWS のサーバーエンドポイントにユーザーのトラフィックをルーティングできます。(インターネット転送エンドポイントにのみ適用可能な) カスタムドメイン名について、AWS Transfer Family が Amazon Route 53 を使用する方法に関するドキュメントを参照してください。

はい。サーバーを作成する際、または既存のサーバーを更新する際に、エンドポイントをパブリックインターネット上でアクセス可能にするか、または自分の VPC 内にホストするか、いずれかを指定することができます。VPC にホストしたエンドポイントをサーバーとして使用すると、同じ VPC にあるクライアント、指定したその他の VPC のクライアント、または AWS Direct Connect、AWS VPN、VPC ピアリングなど、VPC を拡張するネットワーク技術を使用するオンプレミス環境にあるクライアントのみにアクセスを制限できます。サブネットのネットワークアクセスコントロールリスト (NACL) またはセキュリティグループを使用して、さらに VPC 内の特定のサブネットのリソースにアクセスを制限できます。詳細については、AWS PrivateLink を使用して VPC 内にサーバーエンドポイントを作成する方法に関するドキュメントを参照してください。

いいえ。FTP を有効にすると、FTP はデータを平文で送信するため、VPC ホストエンドポイントの内部アクセスオプションしか使用できなくなります。トラフィックがパブリックネットワークを経由する場合は、SFTP や FTPS のようなセキュアなプロトコルを使用する必要があります。

いいえ。FTP サーバーエンドポイントをホストするためには VPC が必須です。CloudFormation テンプレートのドキュメントを参照して、サーバー作成時にエンドポイントをホストする VPC リソースの作成を自動化してください。

はい。サーバーの VPC にホストされたエンドポイントを選択し、インターネットに直接接続するオプションを選択すると、サーバーエンドポイントの固定 IP を有効にできます。これにより、エンドポイントの IP アドレスとして割り当てられているエンドポイントに Elastic IP (BYO IP を含む) を直接接続できるようになります。ドキュメントのインターネット向けエンドポイントの作成に関するセクション「VPC 内でのサーバーエンドポイントの作成」を参照してください。

はい。ユーザーのソース IP アドレスによって着信トラフィックを制限するには、3 つのオプションがあります。VPC 内でサーバーエンドポイントをホストしている場合は、セキュリティグループを使用してソースの IP アドレスを一覧表示できるようにする方法、または AWS ネットワークファイアウォールサービスを使用する方法に関するこのブログ記事を参照してください。パブリック EndpointType Transfer サーバーと API Gateway を使用して ID 管理システムを統合している場合は、AWS WAF を使用して、エンドユーザーのソース IP アドレスによってアクセスを許可、ブロック、またはレート制限することもできます。

はい。共有 VPC 環境を使用して、サーバーエンドポイントをデプロイできます。この環境は、セキュリティ、コスト監視、スケーラビリティのために AWS Landing Zone などのツールを使用して AWS 環境をセグメント化するときに通常使われます。AWS Transfer Family による共有 VPC 環境で VPC ホストエンドポイントを使用する方法については、このブログ投稿を参照してください。

AWS Global Accelerator を転送サーバーエンドポイントで使用すると、ファイル転送のスループットと往復時間を改善できます。詳細については、このブログ記事をご覧ください。

はい。セキュリティとコンプライアンスの要件に基づいて、利用可能なサービスマネージドセキュリティポリシーのいずれかを選択して、サーバーエンドポイントによって通知される暗号化アルゴリズムを制御できます。エンドユーザーの File Transfer クライアントがお使いのサーバーへの接続を試みる場合、接続の交渉にはポリシーで指定されたアルゴリズムのみが使用されます。事前定義されたセキュリティポリシーに関するドキュメントを参照してください。

はい。AWS Transfer Family は、SFTP File Trasnfer 用の耐量子パブリックキー交換のサポートを開始しました。定義済みのハイブリッド PQ セキュリティポリシーの 1 つを SFTP サーバーに関連付けることで、PQ 暗号化アルゴリズムをサポートするクライアントとの量子安全な鍵交換が可能になります。

いいえ。ファイアウォールのホワイトリスト登録に通常使用される固定 IP アドレスは、現在 PUBLIC Endpoint タイプではサポートされていません。 VPC でホストされているエンドポイントを使用して、エンドポイントに静的 IP アドレスを割り当ててください。

PUBLIC エンドポイントタイプを使用している場合、ユーザーはここに公開されている AWS IP アドレス範囲のリストを許可する必要があります。AWS IP アドレス範囲を最新の状態に保つ方法の詳細については、ドキュメントを参照してください。

いいえ。サーバーの作成時に割り当てられたサーバーのホストキーは、新しいホストキーを追加して元のホストキーを手動で削除しない限り、変わりません。

SFTP サーバーのホストキーでは、RSA、ED25519、および ECDSA キータイプがサポートされています。

はい。サーバー作成時にホストキーをインポートしたり、サーバーの更新時に複数のホストキーをインポートすることができます。SFTP 対応サーバーのホストキーの管理に関するドキュメントを参照してください。

はい。各キー種の最も古いホストキーを使用して、SFTP サーバーの真正性を検証することができます。RSA、ED25519、ECDSA のホストキーを追加することで、3 つの別個のホストキーを使用して SFTP サーバーを識別することができます。

A: SFTP サーバーの真正性を検証するために、各キータイプの中で最も古いホストキーが使用されます。

はい。A: SFTP サーバーのホストキーのローテーションは、ホストキーの追加と削除によりいつでも行うことができます。SFTP 対応サーバーのホストキーの管理に関するドキュメントを参照してください。

FTPS アクセスを有効にする場合は、Amazon 証明書マネージャー (ACM) から証明書を提供する必要があります。この証明書を使用して、エンドユーザークライアントは FTPS サーバーの ID を確認します。新しい証明書のリクエストまたは既存の証明書の ACM へのインポートについては、ACM のドキュメントを参照してください。

エンドユーザーのクライアントがサーバーとの接続を開始できるパッシブモードのみをサポートしています。パッシブモードではクライアント側で必要なオープンなポートの数が少なく、サーバーエンドポイントの、保護されたファイアウォールの後ろにいるエンドユーザーとの互換性が高まります。

明示的な FTPS モードのみサポートしています。

はい。ファイアウォールやルーターを経由するファイル転送は、デフォルトでは EPSV (extended passive connection mode) を使用してサポートされています。EPSV モードをサポートしない FTPS/FTP クライアントを使用している場合は、このブログ記事を参照してサーバーを PASV モードに設定し、サーバーの互換性を幅広いクライアントに広げてください。

はい。標準のポート 22 に加えて、AWS Transfer Family は代替ポート 2222 および 22000 もサポートしています。デフォルトでは、ポート 22 が SFTP サーバー用に設定されています。サーバーのセキュリティを強化するために、ポート 22、2222、またはその両方を使用するように SSH トラフィックを設定できます。こちらのドキュメントをご覧ください。

リモートサーバーの要件に応じて、SSH キーペアまたはパスワード、あるいはその両方を使用してリモートサーバーへの接続を認証できます。AWS Secrets Manager アカウントでのコネクタの認証情報の保存と管理の詳細については、ドキュメントにアクセスしてください。 

A: SFTP コネクタを使用して、Amazon S3 との間でファイルをリモートの SFTP サーバーに転送できます。

RSA および ECDSA ホストキーアルゴリズムをサポートしています。サポートされているキータイプの詳細については、こちらのドキュメントをご覧ください。 

コネクタはホストのフィンガープリントを使用してリモートサーバーの識別情報を検証します。リモートサーバーから提供されたフィンガープリントが コネクタ設定にアップロードされたフィンガープリントと一致しない場合、接続は失敗し、エラーの詳細が CloudWatch にログ記録されます。リモートサーバーの SSH キーの公開部分を識別のためにアップロードする方法の詳細については、こちらの SFTP コネクタのドキュメントにアクセスしてください。

はい。Amazon S3 バケットと SFTP コネクタリソースを異なる AWS アカウントにプロビジョニングできます。

はい。セキュリティと互換性の要件に基づいて、使用可能なサービスマネージドセキュリティポリシーのいずれかを選択して、SFTP コネクタによってアドバタイズされる暗号化アルゴリズムを制御できます。コネクタがリモートサーバーへの接続を試みると、コネクタにアタッチされたポリシーで指定されたアルゴリズムのみが接続のネゴシエーションに使用されます。事前定義済みのセキュリティポリシーに関するドキュメントをご覧ください。

はい。ある AWS アカウントで SFTP コネクタを作成し、コネクタにアタッチされている IAM ロールに適切な許可を付与することで、それを使用して別のアカウントからファイルを転送できます。

AWS マネジメントコンソールまたは TestConnection API/CLI/CDK コマンドを使用して、リモートサーバーへの接続をテストできます。 コネクタを作成したらすぐにリモートサーバーへの接続をテストして、正しく構成されていることを確認することをお勧めします。必要に応じて、コネクタに関連付けられた静的 IP アドレスがリモートサーバーによって許可リストに登録されていることを確認してください。詳細については、SFTP コネクタのドキュメントにアクセスしてください。

SFTP コネクタを使用すると、Amazon S3 からリモート SFTP サーバーへのファイルの送信、リモート SFTP サーバーから Amazon S3 へのファイルの取得、およびリモート SFTP サーバー上のディレクトリに保存されているファイルの一覧表示を行うことができます。SFTP コネクタの使用方法の詳細については、SFTP コネクタのドキュメントをご覧ください。

SFTP コネクタの StartDirectoryListing API オペレーションを使用して、リモート SFTP サーバー上のディレクトリに保存されているファイルをリストで表示できます。これにより、StartFileTransfer API オペレーションを使用してファイルを転送する際に、リストに記載されているファイル名を渡すことによって、リモートサーバーからターゲットファイルを取得できるようになります。詳細については、リモート SFTP サーバーから新しいファイルを同期するためのサンプルソリューションを参照するか、セルフペースの MFT ワークショップを受講してください。

SFTP コネクタを使用してリモート SFTP サーバー上のディレクトリからすべてのファイルをリストで表示し、ファイル名のパターンのワイルドカード基準に基づいてファイルリストをフィルタリングするカスタムロジックを構築できます。その後、StartFileTransfer API オペレーションで SFTP コネクタを使用してこれらのファイルを転送できます。

ListFileTransferResults API コマンドを使用して、ファイル転送オペレーションの現在のステータスをモニタリングできます。さらに、SFTP コネクタは、データリネージの維持に役立つよう、ファイル転送のステータス、オペレーションタイプ (送信または取得)、タイムスタンプ、ファイルパス、エラーの説明 (ある場合) などの詳細なログを Amazon CloudWatch に出力します。 

はい。Amazon EventBridge スケジューラを使用してファイル転送をスケジュールできます。EventBridge Scheduler を使用してビジネスのニーズを満たすスケジュールを作成し、AWS Transfer Family の StartFileTransfer API または StartDirectoryListing API をスケジュールのユニバーサルターゲットとして指定します。

はい。AWS Step Functions は、AWS Transfer Family を含むさまざまな AWS サービスと統合されているため、SFTP コネクタの StartFileTransfer アクションをステートマシンから直接呼び出すことができます。AWS Transfer Family を使用して SFTP コネクタを作成したら、Step Functions の AWS SDK インテグレーションを利用して StartFileTransfer API を呼び出します。AWS Step Functions と SFTP コネクタを使用してファイル転送とファイル処理ワークフローをオーケストレートする方法の詳細については、セルフペースのイベント駆動型 MFT ワークショップを受講してください。

はい。SFTP コネクタを使用したあらゆるファイル転送オペレーションは、Amazon EventBridge のデフォルトのイベントバスにイベント通知を発行します。SFTP コネクタイベントをサブスクライブし、Amazon EventBridge またはこれらのイベントと統合する任意の他のワークフローオーケストレーションサービスを利用して、転送されたファイルのイベント駆動型の処理をオーケストレートするために使用できます。

はい。静的 IP アドレスはデフォルトでコネクタに関連付けられており、ビジネスパートナーのファイアウォールで接続を許可リストに登録するために使用できます。コネクタに関連付けられている静的 IP アドレスは、AWS Transfer Family コンソールのコネクタの詳細ページに移動するか、または DescribeConnector の API/CLI/CDK コマンドを使用して確認できます。

はい。AWS アカウントがあるリージョン内のすべての SFTP コネクタは、一連の静的 IP アドレスを共有します。特定のタイプのコネクタ間で IP アドレスを共有すると、許可リストのドキュメントの量が少なくなり、外部パートナーとの間で必要となるオンボーディング通信も少なくなります。

いいえ。現在、SFTP コネクタは、インターネットにアクセスできるエンドポイントを提供するサーバーとの接続にのみ使用できます。プライベートネットワーク経由でのみアクセス可能なサーバーに接続する必要がある場合は、AWS サポートまたは AWS アカウントチームを通じてお知らせください。

はい。設定中に、クライアントがエンドポイントに接続するために有効化したいプロトコル (複数可) を選択できます。サーバーホスト名、IP アドレス、および ID プロバイダーが選択されたプロトコル全体で共有されます。同様に、エンドポイントの設定が、使用するすべてのプロトコルの要件を満たしている限り、既存の AWS Transfer Family エンドポイントに対する追加のプロトコルサポートを有効にすることもできます。

FTP (VPC 内のアクセスでのみサポート) を使用する必要があり、インターネット経由で SFTP、AS2、または FTPS をサポートする必要がある場合は、FTP 用に別のサーバーエンドポイントが必要になります。複数のプロトコルを介して接続するクライアントのために同じエンドポイントのホスト名と IP アドレスを使用する場合は、複数のプロトコルのために同じエンドポイントを使用できます。さらに 1 つの認証情報を SFTP と FTPS に使用したい場合は、単一の ID プロバイダーを設定して使用して、両方のプロトコルにわたって接続するクライアントを認証できます。

はい。1 人のユーザーに複数のプロトコルにわたるアクセスを設定できます。これは ID プロバイダーにプロトコルに固有の認証情報が設定されている場合に可能です。FTP を有効化している場合は、FTP には別の認証情報を使用することを推奨します。FTP に別の認証情報を設定する方法については、ドキュメントを参照してください。

SFTP および FTPS と異なり、FTP は認証情報をクリアテキストで送信します。FTP の認証情報を SFTP または FTPS から隔離することを推奨します。そうすれば、もし不注意により FTP の認証情報が共有または公開されても、SFTP または FTPS を使用しているワークロードは引き続き安全だからです。

はい。AWS Transfer Family SFTP エンドポイントを使用してブラウザベースのインターフェイスを提供できるこのオープンソースソリューションをデプロイできます。

このサービスでは、ユーザー ID をサービス内に保存するサービスマネージド、Microsoft Active Directory、および任意の ID プロバイダーを統合できるカスタム ID プロバイダーの 3 つのオプションをサポートしています。サービスマネージド型認証は、SFTP のみに有効化されたサーバーエンドポイントをサポートしています。

サービスマネージド認証を使用して、SSH キーを使用して SFTP ユーザーを認証できます。

ユーザー 1 人あたり最大 10 個の SSH キーをアップロードできます。RSA、ED25519、ECDSA のキーがサポートされています。

はい。SFTP ユーザーのキーローテーションを設定する方法の詳細については、ドキュメントを参照してください。

サーバーを作成するときに、AWS マネージド Microsoft AD のディレクトリ、オンプレミス環境、または Amazon EC2 のセルフマネージド AD のディレクトリを ID プロバイダーとして選択します。次に、セキュリティ識別子 (SID) によるアクセスを有効にする AD グループを指定する必要があります。AD グループを IAM ロール、スコープダウンポリシー (S3 のみ)、POSIX プロファイル (EFS のみ)、ホームディレクトリの場所、論理ディレクトリマッピングなどのアクセス制御情報に関連付けると、グループのメンバーは AD 認証情報を使用して、有効なプロトコル (SFTP、FTPS、FTP) を介してファイルを認証および転送できます。 

ユーザーを設定する際には、ユーザー名などのユーザー情報に基づいて実行時に評価されるスコープダウンポリシーを指定します。すべてのユーザーに同じスコープダウンポリシーを使用して、バケットの一意のプレフィックスに対するアクセス権を、ユーザー名を基に付与できます。ユーザー名は論理ディレクトリマッピングの評価にも使用できます。これを行うには、S3 バケットまたは EFS ファイルシステムの内容をユーザーに表示する方法を、標準化されたテンプレートで指定します。詳細については、 AD グループへのアクセス権の付与に関するドキュメントをご覧ください。

はい。Microsoft AD を使用して、SFTP、FTPS、および FTP 経由でアクセスするユーザーを認証できます。

はい。個々の AD グループに付与されたファイル転送のアクセス権は取り消すことができます。いったん取り消されると、AD グループのメンバーは AD 認証情報を使用してファイルを転送できなくなります。

カスタムモード (「BYO」認証) では、既存のIDプロバイダーを利用してすべてのプロトコルタイプ (SFTP、FTPS、FTP) のエンドユーザーを管理できるため、ユーザーの移行を簡単かつシームレスに行うことができます。認証情報は社内ディレクトリまたは社内の ID データストアに格納して、エンドユーザー認証のために統合できます。ID プロバイダーの例としては、 Okta 、Microsoft AzureAD、またはプロビジョニングポータル全体の一部として使用しているカスタムビルド ID プロバイダーなどがあります。

ID プロバイダーを AWS Transfer Family サーバーと統合するには、AWS Lambda 関数または Amazon API ゲートウェイエンドポイントを使用できます。ID プロバイダーに接続するための RESTful API が必要な場合や、AWS WAF の地理的ブロックおよびレート制限機能を利用する場合は、Amazon API Gateway を使用してください。AWS Cognito、Okta、AWS Secrets Manager などの一般的なアイデンティティプロバイダーの統合について詳しくは、ドキュメントをご覧ください。

はい。AWS Lambda または API Gateway を使用してカスタム ID プロバイダーを接続する際に、クライアントソース IP がお客様の ID プロバイダーに渡されます。これにより、クライアントの IP アドレスに基づいてアクセスを許可、拒否、制限することができ、信頼できると指定した IP アドレスからのみデータにアクセスできるようになります。

はい。SFTP 経由でデータにアクセスする場合、複数の認証方法を適用してセキュリティを強化できます。SFTP サーバーは、パスワードと SSH キー、パスワードまたは SSH キーの両方、パスワードのみ、または SSH キーのみを要求するように設定できます。カスタマー ID プロバイダーを使用して複数の認証方法を有効にする方法の詳細については、ドキュメントを参照してください。

いいえ。認証用にサービス内にパスワードを保存することは現在サポートされていません。パスワード認証が必要な場合は、AWS Directory Service でディレクトリを選択して Active Directory を使用するか、このブログの「Secrets Manager によるパスワード認証の有効化」で説明されているアーキテクチャに従ってください。

いいえ。匿名ユーザーは現在、どのプロトコルでもサポートされていません。

いいえ。AD グループによるアクセス設定のみをサポートしています。

いいえ。Microsoft AD の AWS Transfer Family サポートは、パスワードベースの認証にのみ使用できます。認証モードを混在させて使用する場合は、カスタムオーソライザーオプションを選択してください。

はい。AS2 の AWS Transfer Family サポートは、ドラモンドグループの公式の AS2 クラウド認定シールを取得しました。AWS Transfer Family AS2 の機能は、他の 14 のサードパーティ AS2 ソリューションとのセキュリティとメッセージ交換の互換性について徹底的に検証されています。詳細については、発表をご覧ください。

取引相手は、AS2 識別子 (AS2 ID) を使用して一意に識別されます。同様に、トレーディングパートナーは AS2 ID を使用してメッセージを特定します。

SFTP、FTPS、FTP と同様に、AWS Transfer Family の既存の Amazon S3 サポート、ネットワーキング機能 (VPC エンドポイント、セキュリティグループ、Elastic IP)、AS2 のアクセスコントロール (AWS IAM) を使用できます。ユーザー認証、論理ディレクトリ、カスタムバナー、ストレージバックエンドとしての Amazon EFS は、AS2 ではサポートされていません。

AS2 特有の否認防止は、メッセージが 2 者間で正常に交換されたことを検証するものです。AS2 における否認防止は、Message Disposition Notifications (MDN) を使用して達成されます。MDN がトランザクションでリクエストされた場合、送信者がメッセージを送信し、受信者がそれを正常に受信し、送信者が送信したメッセージが受信者によって受信されたものと同じメッセージであることを確認します。

メッセージ送信には、送信者からのものと受信者からのものの 2 つの側面があります。送信者が送信するメッセージを決定すると、メッセージは (送信者の秘密キーを使用して) 署名され、(受信者の証明書を使用して) 暗号化され、ハッシュを使用してメッセージの整合性が計算されます。この署名され暗号化されたメッセージは、電信で受信者に送信されます。メッセージが受信されると、(受信者の秘密キーを使用して) 復号化され、(送信者の公開キーを使用して) 検証され、処理され、リクエストがあれば署名された Message Disposition Notifications (MDN) が送信者に送り返され、メッセージの配信が成功したことを確認します。AS2 がメッセージ送信を処理する方法については、ドキュメントを参照してください。

可能なオプションの組み合わせは、送信者の観点から決定されます。送信者は、データの暗号化のみ、署名のみ (または両方) を選択し、Message Disposition Notifications (MDN) をリクエストすることを選択できます。送信者が MDN をリクエストすることを選択した場合、署名付きまたは未署名の MDN をリクエストすることができます。受信者はこれらのオプションを尊重することが期待されます。

はい。送信者は MDN をリクエストするかどうか、署名付きまたは未署名の MDN をリクエストするかどうか、また MDN に署名するために使用すべき署名アルゴリズムを、選択することができます。

現在、同期と非同期の MDN 応答の両方をサポートしています。これにより、AS2 メッセージを受信した後、同期 MDN または非同期 MDN で取引相手に応答することができます。同期型 MDN は、メッセージと同じ接続チャネルで送信されるため、よりシンプルであり、推奨されるオプションです。MDN を送信する前にメッセージの処理に時間が必要な場合は、非同期型 MDN をお勧めします。取引パートナーにメッセージを送信する際に非同期 mDN をリクエストして受信する必要がある場合は、AWS サポートまたはアカウントマネージャーを通じてお問い合わせください。

AWS Transfer Family は、交換されたペイロードと mDN から重要な AS2 情報を抽出し、それらを JSON ファイルとして Amazon S3 バケットに保存します。これらの JSON ファイルは、S3 Select や Amazon Athena でクエリしたり、Amazon OpenSearch や Amazon DocumentDB を使用してファイルのインデックスを作成して分析することができます。

はい。トレーディングパートナーから MDN を受信すると、サービスはお客様の証明書を使用して MDN を検証し、お客様の Amazon S3 バケットにメッセージを保存します。S3 ライフサイクルポリシーを活用することで、メッセージをアーカイブすることを選択できます。

データを配信する準備ができたら、受信者の AS2 サーバー情報を含む AS2 コネクターを使用して StartFileTransfer API を呼び出す必要があります。これにより、取引相手のサーバーにメッセージを送信するようサービスに通知されます。AS2 経由で取引相手にメッセージを送信するには、コネクタに関するドキュメントを参照してください。

はい。トレーディングパートナーのプロファイルをセットアップする際に、トレーディングパートナーごとに異なるフォルダを使用することができます。

はい。パートナーの既存のキーと証明書をインポートし、更新とローテーションを管理することができます。証明書のインポートに関するドキュメントを参照してください。

AWS Transfer Family コンソールを使用すると、有効期限ごとに分類された証明書のダッシュボードを表示できます。また、証明書の有効期限が切れる前に通知を受け取るように設定することができますので、運用の中断を防ぐために十分な時間をかけて証明書をローテーションすることができます。

はい。静的 IP アドレスはデフォルトでコネクタに関連付けられており、取引パートナーの AS2 サーバーで接続を許可リストに登録するために使用できます。コネクタに関連付けられている静的 IP アドレスは、AWS Transfer Family コンソールのコネクタの詳細ページに移動するか、または DescribeConnector の API/CLI/CDK コマンドを使用して確認できます。

はい。基本認証を使用して取引パートナーの AS2 サーバーに接続する機能がサポートされています。AS2 コネクタでの基本認証の設定に関するドキュメントをご覧ください。

はい。AS2 コネクタは、リモート AS2 サーバーにメッセージを送信するとき、および非同期の Message Disposition Notification (MDN) 応答を返すときに、静的 IP アドレスを使用します。コネクタに関連付けられた静的 IP アドレスを特定するには、AWS Transfer Family マネジメントコンソールでコネクタまたはサーバーの詳細のページに移動するか、または DescribeConnector もしくは DescribeServer API/CLI/CDK コマンドを使用します。

はい。AS2 サーバーエンドポイントは、インターネットに接続された VPC ホスト型エンドポイントでセキュリティグループを使用することによって、IP 許可リストのコントロールの設定をサポートします。

はい。AS2 非同期 MDN 応答は静的 IP アドレスを使用します。非同期 MDN 応答の送信に使用される静的 IP アドレスは、AWS Transfer Family マネジメントコンソールのサーバーの詳細ページに移動するか、または DescribeServer の API/CLI/CDK コマンドを使用して確認できます。

受信したすべての AS2 メッセージは、Amazon EventBridge のデフォルトのイベントバスにイベントを発行します。これらのイベントをサブスクライブし、Amazon EventBridge または他のワークフローオーケストレーションサービスを利用して、受信したメッセージのイベント駆動型の処理をオーケストレートするために使用できます。例えば、これらのイベントを使用して、着信メッセージを S3 の他の場所にコピーしたり、カスタム Lambda を利用してメッセージのコンテンツをスキャンし、マルウェアが含まれていないかどうかを確認したりできるほか、Amazon CloudSearch などのサービスによるインデックス作成や検索を可能にするために、コンテンツに基づいてメッセージにタグを付けることもできます。

はい。AWS B2B Data Interchange を利用して、インバウンド AS2 メッセージの X12 EDI コンテンツを JSON や XML などの一般的なデータ表現に自動的に変換できます。これを実行するには、AWS Transfer Family の AS2 Payload Receive Completed イベントのイベントパターンと照合する Amazon EventBridge ルールを作成し、AWS B2B Data Interchange の StartTransformerJob API を、ルールのユニバーサルターゲットとして指定します。インバウンド AS2 メッセージの X12 EDI コンテンツを AWS B2B Data Interchange で変換することで、ダウンストリームビジネスアプリケーションおよびシステムへの EDI データの統合を自動化および加速できます。

AS2 メッセージの送信は、Amazon EventBridge スケジューラを使用してスケジュールするか、または Amazon EventBridge ルールを使用してトリガーすることによって自動化できます。AS2 メッセージを送信するための自動化された時間ベースのワークフローを作成するには、EventBridge スケジューラを使用してビジネスニーズを満たすスケジュールを作成し、AWS Transfer Family の StartFileTransfer API を、スケジュールのユニバーサルターゲットとして指定します。AS2 メッセージを送信するための自動化されたイベント駆動型のワークフローを作成するには、EventBridge に発行されたイベントと照合する Amazon EventBridge ルールを作成し、AWS Transfer Family の StartFileTransfer API を、ルールのユニバーサルターゲットとして指定します。

はい。送信されたすべての AS2 メッセージと MDN は、Amazon EventBridge のデフォルトのイベントバスにイベントを発行します。これらのイベントをサブスクライブし、取引パートナーに正常に送信された AS2 メッセージや MDN を削除またはアーカイブするために使用できます。

はい。AWS Transfer Family は、成功または失敗した AS2 メッセージまたは送受信された MDN ごとにイベントを Amazon EventBridge に発行します。これらのイベントは、Amazon EventBridge のデフォルトのイベントバスに発行され、Amazon SNS などのサービスを使用して、ユーザー、またはユーザーのパートナーに対する E メール通知をトリガーするために使用できます。

いいえ。現在、マネージドワークフローは AS2 エンドポイントについてサポートされていません。AS2 メッセージの処理をオーケストレートするには、Amazon EventBridge で発行される Transfer Family のイベント通知を使用することをお勧めします。詳細については、「ファイル処理のオートメーション」セクションをご覧ください。

いいえ。現時点では、AWS Transfer Family は AS3 または AS4 のサポートを提供していません。

2 つのオプションがあります。1) AWS Transfer Family は、SFTP、AS2、FTPS、FTP 経由で転送されたファイルについてのファイル転送イベント通知を Amazon EventBridge に発行します。ユーザーはこれらのイベントを使用して、EventBridge と統合できるサービスを利用してファイルの処理をトリガーできます。2) AWS Transfer Family は、事前構築済みのファイル処理ステップを使用して、SFTP、FTPS、および FTP サーバーエンドポイント経由でアップロードされたファイルのアップロード後の処理を自動的かつ簡単に実行できるようにするマネージドワークフローを提供します。マネージドワークフローをサーバーエンドポイントに関連付ける場合、そのエンドポイント経由でアップロードされるすべてのファイルは、同じワークフローステップを使用して処理されます。

AWS Transfer Family は、サーバーとコネクタのリソースの両方について、各ファイル転送オペレーションの成功または失敗の完了時に Amazon EventBridge でイベント通知を発行します。Amazon EventBridge に発行される Transfer Family イベントの詳細については、ドキュメントをご覧ください。 

ビジネスパートナーと交換するファイルを処理する必要がある場合は、カスタムコードを実行するためのインフラストラクチャをセットアップし、実行時のエラーや異常を継続的に監視し、データへのすべての変更と変換が監査および記録されていることを確認する必要があります。さらに、技術的なものとビジネス的なものの両方のエラーシナリオを考慮し、フェイルセーフモードが適切にトリガーされるようにする必要があります。また、トレーサビリティーが必要な場合は、データがシステムのさまざまなコンポーネントを通過する際に、データの系統を追跡する必要があります。ファイル処理ワークフローの個別のコンポーネントを維持することは、ビジネスのためにできるであろう差別化のための仕事に集中する時間を奪うことになります。マネージドワークフローは、複数のタスクを管理する複雑さを取り除き、組織全体で複製可能な標準化されたファイル処理ソリューションを提供します。また、各ステップで例外処理とファイルのトレーサビリティが組み込まれており、ビジネス要件と法的要件を満たすのに役立ちます。

AWS Transfer Family マネージドワークフローは、SFTP、FTPS、および FTP サーバーエンドポイント経由でアップロードされたファイルを処理するための一連の直線的なステップを作成、実行、モニタリングできるようにするための事前構築済みのフレームワークを提供します。この機能で、ファイルのコピー、タグ付け、復号などの一般的なファイル処理タスクを実行するための事前構築済みのステップを使用することで、時間を節約できます。また、Lambda 関数を使用して、PII、ウイルス/マルウェア、または不正なファイル形式やタイプなどのエラーがないかどうかを確認するためのファイルのスキャンなどのタスクのファイル処理をカスタマイズすることもできるため、異常を迅速に検出してコンプライアンス要件を満たすことができます。マネージドワークフローをサーバーエンドポイントに関連付ける場合、そのエンドポイント経由でアップロードされるすべてのファイルは、同じワークフローステップを使用して処理されます。

マネージドワークフローを使用すると、サーバーエンドポイントにアップロードされたすべてのファイルについて、直線的なファイル処理タスク (アップロードされたファイルのユーザー固有のフォルダへの移動や、PGP キー、マルウェアスキャン、およびタグ付けを使用したファイルの復号など) を実行することで、ダウンストリームアプリケーションによって利用される前にデータを簡単に前処理できます。Infrastructure as Code (IaC) を使用してワークフローをデプロイすることで、組織内の複数のビジネスユニットにまたがる共通のアップロード後ファイル処理タスクを迅速に複製し、標準化することができます。 完全にアップロードされたファイルに対してのみトリガーされるマネージドワークフローをサーバーエンドポイントに関連付けたり、不完全なアップロードを処理するために、部分的にアップロードされたファイルについてのみトリガーされる別のマネージドワークフローを関連付けたりすることで、きめ細かいコントロールが可能になります。また、ワークフローには組み込みの例外処理も用意されており、ワークフローの実行においてエラーや例外が発生した場合にファイル処理の結果に簡単に対応できるため、ビジネスおよび技術的な SLA の維持に役立ちます。ワークフロー内の各ファイル処理ステップでは、詳細なログも生成され、これを監査してデータリネージを追跡できます。

AWS Transfer Family サーバーエンドポイントとコネクタは、ファイル転送オペレーションが完了すると、ファイルの場所、送信者のユーザー名、サーバー ID またはコネクタ ID、転送ステータスなどのオペレーションに関する情報とともに、イベント通知を Amazon EventBridge に自動的に発行します。これらのイベントは、ファイルのソースに基づいた条件付きロジックの使用など、ファイル処理の定義できめ細かなコントロールが必要な場合、または他の AWS サービス、サードパーティーのアプリケーション、および独自のアプリケーションと統合するためにイベント駆動型のアーキテクチャを構築する必要がある場合に使用できます。一方、AWS Transfer Family マネージドワークフローは、SFTP、FTPS、および FTP サーバーエンドポイント経由でアップロードされるすべてのファイルに適用される、共通の直線的なファイル処理ステップを定義するための事前構築済みフレームワークを提供します。アップロードされたすべてのファイルを、同じ共通のファイル処理ステップを使用して処理する必要がある場合、きめ細かなロジックや条件付きロジックを適用することなく、マネージドワークフローをエンドポイントに関連付けることができます。

まず、コピー、タグ付けなどのアクションと、要件に基づいて一連のステップに独自のカスタムステップを含めることができる一連のアクションを含むようにワークフローを設定します。次に、ワークフローをサーバーにマッピングすることで、ファイルの到着時に、このワークフローで指定されたアクションがリアルタイムで評価され、トリガーされます。詳細については、ドキュメントにアクセスするか、またはマネージドワークフローの開始方法に関するこのデモをご視聴ください。あるいは、このブログ記事を参照して、クラウドネイティブのファイル転送プラットフォームをデプロイすることもできます。

はい。同じワークフローを複数のサーバーに関連付けることができるため、設定のメンテナンスと標準化が容易になります。

はい。当初アップロードされたファイルまたは前のワークフローステップの出力ファイルのいずれかを処理するようにワークフローステップを設定することができます。これにより、Simple Storage Service (Amazon S3) にアップロードされた後のファイルの移動や名前の変更を簡単に自動化することができます。例えば、ファイルのアーカイブや保持のためにファイルを別の場所に移動するには、ワークフローで 2 つのステップを構成します。最初のステップは、ファイルを別の Simple Storage Service (Amazon S3) の場所にコピーすることであり、2 番目のステップは、当初アップロードされたファイルを削除することです。ワークフローステップのファイル保存場所の選択に関する詳細については、ドキュメントをお読みください。

転送サーバーがクライアントからファイルを受信すると、次の一般的なアクションを実行できます。

PGP キーを使用したファイルの復号。PGP によるファイルの暗号化と復号化に関するこのブログ記事を参照してください。

到達した場所から消費されるべき場所にデータを移動またはコピーする。

アーカイブまたは新しい場所にコピーした後、元のファイルを削除してください。

ファイルの内容に応じてタグ付けし、下流のサービス (S3 のみ) でインデックスを付けて検索できるようにする

独自の Lambda 関数をワークフローのカスタムステップとして提供することによる、任意のカスタムファイル処理ロジック。例えば、データ分析にファイルを取り込む前に、ファイルタイプの互換性チェック、ファイルのマルウェアスキャン、個人を特定できる情報 (PII) の検出、メタデータの抽出を実行するなどです。

はい。SFTP、FTPS、および FTP サーバーエンドポイント経由でアップロードされたファイルの PGP 復号には、事前構築済みのフルマネージドワークフローステップを使用できます。詳細については、PGP を使用したファイルの暗号化と復号に関するマネージドワークフローのドキュメントと、このブログの記事をご覧ください。

サーバーエンドポイントに最初にアップロードされたファイル、またはワークフローの前のステップからの出力ファイルのいずれかを処理するようにワークフローステップを設定できます。これにより、Simple Storage Service (Amazon S3) にアップロードされた後のファイルの移動や名前の変更を簡単に自動化することができます。例えば、ファイルのアーカイブや保持のためにファイルを別の場所に移動するには、ワークフローで 2 つのステップを構成します。最初のステップは、ファイルを別の Simple Storage Service (Amazon S3) の場所にコピーすることであり、2 番目のステップは、当初アップロードされたファイルを削除することです。ワークフローステップのファイルの場所の選択の詳細については、ドキュメントをご覧ください。

はい。マネージドワークフローを使用すると、記録の保持のために元のファイルを保存しながら、元のファイルのコピーを複数作成できます。

はい。ワークフローのコピー手順でユーザーネームを変数として利用できます。これにより、Simple Storage Service (Amazon S3) のユーザー固有のフォルダにファイルを動的にルーティングできます。これは、ファイルをコピーするときに宛先フォルダの場所をハードコーディングする必要性を排除し、Simple Storage Service (Amazon S3) でのユーザー固有のフォルダの作成が自動化するため、ファイルオートメーションワークフローをスケールすることを可能にします。詳細については、ドキュメントをお読みください。

AWS Step Functions は、AWS Lambda を他のサービスと組み合わせて、ビジネスアプリケーションの実行を簡単なステップで定義できるサーバーレスオーケストレーションサービスです。AWS Step Functions を使用してファイル処理のステップを実行するには、AWS Lambda 関数と Amazon S3 のイベントトリガーを使用して、お客様独自のワークフローを組み立てます。マネージドワークフローは、直線的な一連の処理を簡単にオーケストレートするためのフレームワークを提供し、以下の点で既存のソリューションとは異なります。1) 完全なファイルのアップロード時のみ実行するワークフローと、部分的なファイルのアップロード時のみ実行するワークフローをきめ細かく定義できる、2) ワークフローは S3 だけでなく EFS (アップロード後のイベントを提供しない) に対しても自動的にトリガーされる、3) ワークフローは PGP 複合のような共通ファイル処理のコードや事前に作られたオプションを提供しません 4) お客様は CloudWatch ログで File Trasnfer と処理をエンドツーエンドで可視化できる、という点です。

マネージドワークフローアクティビティのログ記録のためにサポートされている機能の詳細については、「モニタリング」セクションをご覧ください。

はい。ファイル配信通知のためのマネージドワークフローの使用については、このブログ記事をご覧ください。

はい。ファイルの完全なアップロードとファイルの部分的なアップロードでトリガーされる個別のワークフローを定義できます。

いいえ。処理は、受信エンドポイントを使用してファイルが到着したときにのみ呼び出すことができます。

現在、マネージドワークフローは、SFTP、FTPS、および FTP サーバーエンドポイント経由でアップロードされたファイルのためにのみトリガーでき、実行ごとに 1 つのファイルを処理します。マネージドワークフローは、AS2 経由で交換されるメッセージ、サーバーエンドポイント経由のファイルダウンロード、および SFTP コネクタを使用して転送されるファイルについてはサポートされていません。

いいえ。現在、ワークフローは 1 回の実行で 1 つのファイルを処理します。

いいえ。マネージドワークフローは、ユーザーごとにきめ細かく呼び出すことはできません。Amazon EventBridge で発行されるファイル転送イベント通知を使用して、どのユーザーがファイルをアップロードしたかに基づいて、条件付きファイル処理ロジックを定義できます。

AWS Transfer Family サーバーと Amazon S3 間のデータ転送は、AWS の内部ネットワークを介して行われ、パブリックインターネットを経由しません。このため、AWS Transfer Family サーバーから Simple Storage Service (Amazon S3) へ転送するデータには、AWS PrivateLink を使用する必要はありません。Transfer Family サービスは、トラフィックがインターネットを経由しないようにするために Simple Storage Service (Amazon S3) 用の AWS PrivateLink エンドポイントを必要としないので、ストレージサービスとの通信にそれらを使用することはできません。これはすべて、AWS のストレージサービスと Transfer Family サーバーが同じリージョンにあると仮定します。

AWS IAM は、ユーザーに提供するアクセスレベルを決定するために使用されます。これには、クライアントで有効にする操作、ユーザーにアクセス権を付与する Amazon S3 バケット (バケット全体、バケットの一部を問わない) が含まれます。

A: ユーザーに設定するホームディレクトリで、ユーザーのログインディレクトリを指定します。これが、サーバーへの認証が成功すると、ユーザーのクライアントが位置するディレクトリパスになります。与えられたIAMロールにより、必ずユーザーがホームディレクトリへアクセスできるようにしなければなりません。

はい。単一の IAM ロールをすべてのユーザーにアサインし、ディレクトリの論理マッピングを使用できます。このマッピングで、Amazon S3 のどの絶対パスがエンドユーザーに表示されるか、またクライアントがどのようにこれらのパスをエンドユーザーに表示するかを指定できます。chroot と論理ディレクトリを使用して AWS SFTP/FTPS/FTP 構造を簡素化する方法については、このブログをご覧ください。

A: サポート対象のプロトコルを介して転送されたファイルは、オブジェクトとして Amazon S3 バケットに保存されます。ファイルとオブジェクト間は 1 対 1 でマッピングされるため、処理や分析用の AWS のサービスを使用して、これらのオブジェクトにネイティブにアクセスすることが可能となります。

A: ユーザーの認証情報に基づき認証が成功した後、サービスでは Amazon S3 のオブジェクトとフォルダがファイルとディレクトリとしてユーザーの転送アプリケーションに表示されます。

ファイルやディレクトリを作成、読み取り、更新、削除するための一般的なコマンドがサポートされています。ファイルは Amazon S3 バケットに個々のオブジェクトとして保存されます。ディレクトリは S3 コンソールと同じ構文を使用して、S3 内のフォルダオブジェクトとして管理されます。

ディレクトリのリネーム操作、追加操作、所有権、許可、タイムスタンプの変更、シンボリックリンクとハードリンクの使用は、現在サポートされていません。

はい。ユーザー名にマッピングしている AWS IAM ロールを使用して、ファイル操作を有効/無効にできます。エンドユーザーのアクセスを制御するには、IAM ポリシーとロールの作成に関するドキュメントを参照してください。

はい。ユーザーがアクセスできるバケットは、AWS IAM ロールと、そのユーザーに割り当てたオプションの scope-down policy によって決定されます。そのユーザーのホームディレクトリとして使用できるバケットは 1 つのみです。

はい。S3 アクセスポイントのエイリアスを AWS Transfer Family と併用することで、単一のバケットポリシーを管理することなく、大規模なデータセットへのきめ細かなアクセスを提供することができます。S3 アクセスポイントのエイリアスと AWS Transfer Family の論理ディレクトリを組み合わせることで、さまざまなアプリケーション、チーム、部門に対してきめ細かなアクセスコントロールを作成できると同時に、バケットポリシーの管理にかかるオーバーヘッドを削減できます。詳細と開始方法については、 AWS Transfer Family と Amazon S3 アクセスポイントによるデータアクセス制御の強化に関するブログ投稿をご覧ください。

はい。CLI と API を使用して、サポート対象のプロトコルで送信されたファイルを格納するバケットとサーバー間のクロスアカウントアクセスを設定できます。コンソールのドロップダウンには、アカウント A にあるバケットしか表示されません。さらに、ロールが、アカウント A に属しているユーザーに割り当てられていることを確認する必要もあります。

はい。AWS Transfer Family は、ファイル転送オペレーションの完了時に Amazon EventBridge でイベント通知を発行します。ユーザーはこれらのイベントを使用して、ファイルのアップロード後の処理を自動化できます。あるいは、アップロードされたすべてのファイルを、条件付きロジックなしで同じファイル処理ステップを使用して処理する必要がある場合は、AWS Transfer Family マネージドワークフローを使用して、ユーザーが SFTP、FTPS、または FTP サーバーエンドポイント経由でアップロードするファイルごとに自動的に呼び出される共通の直線的なファイル処理ステップを定義できます。

はい。ユーザーがファイルをアップロードすると、アップロードに使用されたユーザー名とサーバー ID が、関連する S3 オブジェクトのメタデータの一部として格納されます。アップロード後の処理で使用する情報についてのドキュメントをご覧ください。また、エンドユーザーの情報は、Amazon EventBridge で AWS Transfer Family によって発行される自動ファイルアップロードイベント通知でも確認できます。この情報を使用して、ユーザーに基づいてファイルのアップロード後の処理をきめ細かくオーケストレートできます。 

Amazon S3 は、バケット内に作成された新しいオブジェクトについてのイベント通知を発行できます。一方、AWS Transfer Family は、各ファイル転送オペレーションの成功または失敗の完了時にイベント通知を発行します。AWS Transfer Family は、次の点で Amazon S3 イベント通知とは異なります。1) Transfer Family からのイベント通知を使用する場合、ファイルの完全なアップロードおよびファイルの部分的なアップロードについてのアップロード後の処理を定義する際に、きめ細かく制御できます。2) Transfer Family イベントは、S3 と EFS の両方におけるファイルアップロードについて発行されます。3) Transfer Family によって生成されたイベントには、送信者のユーザー名、サーバー ID、転送ステータスなどのオペレーションに関する情報が含まれており、これらの属性に対する条件付きロジックに基づいて、ファイル処理をきめ細かく定義できます。

はい。エンドユーザーがディレクトリのリスティングを数分から数秒に高速化できるように、S3 ディレクトリのリスティングを最適化できます。2023 年 11 月 17 日よりも後にコンソールを通じて新しいサーバーを作成する場合、ストレージとして Amazon S3 を利用しているときは、サーバーでは最適化された S3 ディレクトリのリスティングがデフォルトで有効になります。これはいつでもオンまたはオフに切り替えることができます。この機能をオフにすると、S3 ディレクトリのリスティングがデフォルトのパフォーマンスに復元されます。CloudFormation、CLI、または API を使用してサーバーを作成している場合、最適化された S3 ディレクトリのリスティングはデフォルトで無効になっていますが、いつでも有効にすることができます。最適化された S3 ディレクトリのリスティングを有効にする方法については、ドキュメントをご覧ください。

セッションポリシーの使用方法や他の内部的な要件によりますが、通常は、ユーザーが意図したファイルのみにアクセスできるようにする上で、セッションポリシーと論理ディレクトリの両方は必要ありません。論理ディレクトリマッピングでは、ユーザーは指定された論理パスとサブディレクトリへのアクセスのみが許可され、論理ルートを横断する相対パスは禁止されます。相対要素を含む可能性のある相対表記を使用してすべてのパスを検証し、これらのパスを S3 に渡す前に解決を積極的にブロックして、ユーザーが論理マッピングを超えて移動するのを防ぎます。 

Amazon EFS ファイルシステムを使用するように AWS Transfer Family を設定する前に、AWS Transfer Family ユーザーに割り当てる予定の POSIX ID (ユーザー ID/グループ ID) を使用してファイルとフォルダの所有権を設定する必要があります。さらに、別のアカウントのファイルシステムにアクセスする場合は、アカウント間のアクセスを有効にするために、ファイルシステムでリソースポリシーも設定する必要があります。 EFS で AWS Transfer Family を使用する手順については、このブログ投稿を参照してください。

AWS Transfer Family サーバーと Amazon EFS 間のデータ転送は、AWS の内部ネットワークを介して行われ、パブリックインターネットを経由しません。このため、AWS Transfer Family サーバーから Amazon EFS に転送するデータには、AWS PrivateLink を使用する必要はありません。Transfer Family サービスは、トラフィックがインターネットを経由しないようにするために Amazon EFS 用の AWS PrivateLink エンドポイントを必要としないので、ストレージサービスとの通信にそれらを使用することはできません。これはすべて、AWS のストレージサービスと Transfer Family サーバーが同じリージョンにあると仮定します。

Amazon EFS は、オペレーティングシステムのユーザー ID、グループ ID、およびセカンダリグループ ID で構成される POSIX ID を使用してファイルシステムへのアクセスを制御します。AWS Transfer Family コンソール/CLI /API でユーザーを設定するときは、EFS ファイルシステムにアクセスするためにユーザー名、ユーザーの POSIX 設定、IAM ロールを指定する必要があります。また、EFS ファイルシステム ID と、オプションでそのファイルシステム内のディレクトリをユーザーのランディングディレクトリとして指定する必要があります。AWS Transfer Family ユーザーがファイル転送クライアントを使用して正常に認証されると、指定されたホームディレクトリ、または指定された EFS ファイルシステムのルート内に直接配置されます。オペレーティングシステムの POSIX ID は、ファイル転送クライアントを介して行われるすべてのリクエストに適用されます。EFS 管理者は、AWS Transfer Family ユーザーにアクセスさせたいファイルとディレクトリが、EFS ファイルシステム内の対応する POSIX ID によって所有されていることを確認する必要があります。EFS のサブディレクトリの所有権の設定の詳細については、ドキュメントを参照してください。ストレージに Amazon EFS を使用している場合、Transfer Family はアクセスポイントをサポートしないことに注意してください。 

有効なプロトコルで転送されたファイルは、Amazon EFS ファイルシステムに直接保存され、標準のファイルシステムインターフェイスを介して、または Amazon EFS ファイルシステムにアクセスできる AWS サービスからアクセスできます。

A: ファイル、ディレクトリ、およびシンボリックリンクを作成、読み取り、更新、および削除するための SFTP/FTPS/FTP コマンドがサポートされています。EFS および S3 でサポートされているコマンドについては、以下の表を参照してください。

1.ファイル名の変更のみがサポートされています。ディレクトリの名前変更および既存のファイルを上書きするためのファイルの名前変更はサポートされていません。

2.ルート、つまり uid=0 のユーザーのみが、ファイルとディレクトリの所有権と許可を変更できます。

3.ルート (例: uid=0)、またはファイルのグループをセカンダリグループの 1 つに変更することしかできないファイルの所有者向けにサポートされています。

4.空でないフォルダでのみサポートされています。

AWS Transfer Family ユーザーに提供する IAM ポリシーによって、そのユーザーがファイルシステムへの読み取り専用、読み取り/書き込み、およびルートアクセス権を持っているかどうかが決まります。さらに、ファイルシステム管理者は、ユーザー ID とグループ ID を使用して、ファイルシステム内のファイルとディレクトリにアクセスするための所有権と許可を設定できます。これは、ID がサービス内に保管されているか (サービス管理)、ID 管理システム内に保管されているか (「BYO 認証」) にかかわらず、ユーザーに適用されます。

はい。ユーザーを設定するときに、ユーザーごとに異なるファイルシステムとディレクトリを指定できます。認証が成功すると、EFS は、有効化されたプロトコルを使用して行われたすべてのファイルシステムリクエストに対してディレクトリを適用します。

はい。AWS Transfer Family 論理ディレクトリマッピングを使用すると、絶対パスをエンドユーザーに表示されるパス名にマッピングすることで、エンドユーザーにファイルシステム内のディレクトリが表示されないようにすることができます。これには、指定されたホームディレクトリにユーザーを「chroot」できることも含まれます。

はい。ユーザーがアクセスできるディレクトリにシンボリックリンクが存在し、ユーザーがそれらにアクセスしようとすると、リンクはターゲットに解決されます。論理ディレクトリマッピングを使用してユーザーのアクセスを設定する場合、シンボリックリンクはサポートされません。

はい。AWS Transfer Family ユーザーを設定する際、ユーザー設定の一部として提供する IAM ポリシーで 1 つ以上のファイルシステムを指定することで、複数のファイルシステムへのアクセスを許可できます。

Microsoft Windows、Linux、macOS、または SFTP/FTPS/FTP をサポートする任意のオペレーティングシステム用に構築されたクライアントとアプリケーションを使用して、EFS ファイルシステムに保存されているファイルをアップロードしてアクセスできます。すべてのオペレーティングシステムでファイルシステムにアクセスできるようにするには、サーバーと、EFS ファイルシステムへの適切なアクセス許可を持つユーザーを設定するだけです。

次の 2 つのオプションがあります。1) AWS Transfer Family はファイル転送オペレーションの完了時に Amazon EventBridge でイベント通知を発行し、ユーザーはこれらのイベントを使用してファイルのアップロード後の処理を自動化できます。2) アップロードされたすべてのファイルを、条件付きロジックなしで同じファイル処理ステップを使用して処理する必要がある場合は、AWS Transfer Family マネージドワークフローを使用して、SFTP、FTPS、または FTP サーバーエンドポイント経由でアップロードされた各ファイルに適用される、共通の直線的なファイル処理ステップを定義できます。

新しいファイルの場合、ファイルをアップロードしたユーザーに関連付けられた POSIX ユーザー ID が、EFS ファイルシステムのファイルの所有者として設定されます。さらに、Amazon CloudWatch を使用して、ファイルの作成、更新、削除、および読み取り操作に関するユーザーのアクティビティを追跡できます。Amazon CloudWatch ログ記録を有効にする方法の詳細については、ドキュメントをご覧ください。

はい。CLI と API を使用して、AWS Transfer Family リソースと EFS ファイルシステム間のクロスアカウントアクセスを設定できます。AWS Transfer Family コンソールは、同じアカウントのファイルシステムのみを一覧表示します。さらに、ファイルシステムにアクセスするためにユーザーに割り当てられた IAM ロールがアカウント A に属していることを確認する必要があります。

クロスアカウントアクセスが有効になっていないクロスアカウント EFS ファイルシステムにアクセスするように AWS Transfer Family サーバーを設定した場合、SFTP/FTP/FTPS ユーザーはファイルシステムへのアクセスを拒否されます。サーバーで CloudWatch ログ記録を有効にしている場合、クロスアカウントアクセスエラーは CloudWatch Logs に記録されます。

いいえ。AWS Transfer Family を使用して同じ AWS リージョンの EFS ファイルシステムにのみアクセスできます。

はい。AWS Transfer を使用してファイルを EFS に書き込み、EFS Lifecycle Management を設定して、一定期間アクセスされていないファイルを低頻度アクセス (IA) ストレージクラスに移行できます。

はい。Amazon EFS にはファイルシステムインターフェイスとファイルシステムのアクセスセマンティクス (強い整合性やファイルのロックなど) が用意されており、最大数千の NFS/SFTP/FTPS/FTP クライアントからの同時アクセスが可能なストレージが提供されます。

はい。AWS Transfer Family サーバーを使用して EFS ファイルシステムにアクセスすると、スループットモードに関係なく、EFS バーストクレジットが消費されます。 使用可能なパフォーマンスモードとスループットモードに関するドキュメントを参照して、パフォーマンスに関する役立つヒントを確認してください。

A: パブリックネットワーク上でのセキュアな送信のためには、SFTP または FTPS を使用する必要があります。SSH および TLS 暗号化アルゴリズムに基づくプロトコルの基盤となるセキュリティにより、データとコマンドはセキュアな暗号化されたチャネルを通して送信されます。

バケットに保存されているファイルを、Amazon S3 サーバー側暗号化 (SSE-S3) または Amazon KMS (SSE-KMS) のどちらを使用して暗号化するかを選択できます。 EFS に保管されているファイルの場合、保管中のファイルの暗号化に AWS またはカスタマーマネージド CMK を選択できます。Amazon EFS を使用してファイルデータとメタデータを保存時に暗号化するオプションの詳細については、ドキュメントを参照してください。

AWS Transfer Family は PCI-DSS、GDPR、FedRAMP、および SOC 1、2、3 に準拠しています。このサービスは HIPAA にも準拠しています。コンプライアンスプログラムによる対象サービスの詳細をご覧ください。

AWS 東西リージョンと GovCloud (米国) リージョンは FISMA に準拠しています。FedRAMP の認定を受けた AWS Transfer Family は、該当リージョン内で FISMA への準拠が認められます。この 2 つのリージョンの FedRAMP Authorization により、FedRAMP 中および FedRAMP 高のコンプライアンスが証明されています。コンプライアンスは、システムセキュリティ計画の範囲に含まれる NIST SP 800-53 による毎年の評価と記録により証明されています。アーティファクトではテンプレートと CRM (Customer Responsibility Matrix) を使用できます。CRM は、FedRAMP で要求されているこうした NIST の規制を満たすための基準や責任を示すものです。アーティファクトは、East/West と GovCloud の両方の AWS アカウントでアクセスできるマネジメントコンソールから使用できます。このトピックについてさらに質問がある場合は、コンソールを参照してください。

サービスを通じてアップロードされたすべてのファイルは、ファイルのアップロード前とアップロード後の MD5 チェックサムを比較することで検証されます。

AWS Transfer Family マネージドワークフローを使用すると、ファイルが AWS Transfer Family の SFTP、FTPS、または FTP サーバーエンドポイントにアップロードされる際に、PGP キーを使用してファイルを自動的に復号できます。詳細については、マネージドワークフローのドキュメントを参照してください。あるいは、Amazon Eventbridge で発行される AWS Transfer Family イベント通知をサブスクライブし、独自の暗号化/復号ロジックを使用して転送されたファイルのきめ細かなイベント駆動型の処理をオーケストレートすることもできます。

Amazon CloudWatch に配信される JSON 形式のログを使用して、エンドユーザーとその File Trasnfer アクティビティをモニタリングできます。新しい形式を使用すれば、JSON 形式のフィールドを自動的に検出する CloudWatch Log Insights を使用して、ログを簡単に分析してクエリできます。また、CloudWatch コントリビューターインサイトを使用して、トップユーザー、ユニークユーザーの総数、およびそれらの継続的な使用状況を追跡することもできます。また、AWS Transfer Family マネジメントコンソールからアクセスできる、事前に作成された CloudWatch メトリックスとグラフも提供しています。詳細については、ドキュメントをご覧ください。

はい。複数の AWS Transfer Family サーバーからのログストリームを 1 つの CloudWatch ロググループにまとめることができます。これにより、統合されたログメトリクスと可視化を作成できるようになり、CloudWatch ダッシュボードに追加することで、サーバーの使用状況やパフォーマンスの追跡に活用することができます。

ワークフローの実行は、ワークフローの合計実行数、成功した実行数、失敗した実行数などの AWS CloudWatch メトリクスを使用してモニタリングできます。AWS マネジメントコンソールを使って、進行中のワークフローの実行状況を検索し、リアルタイムで確認することもできます。ワークフローの実行の詳細なログを取得するには、CloudWatch Logs を利用します。

AWS Transfer Family は、すべてのリソース (サーバー、コネクタ、ワークフローを含む) とすべてのプロトコル (SFTP、FTPS、FTP、AS2 を含む) において、JSON 形式でログを提供します。

Transfer Family のマネージドワークフローを使用して、SFTP、FTPS、および FTP サーバーエンドポイント経由でアップロードされたファイルについての通知を受け取ることができます。このブログ記事をご覧ください。あるいは、Amazon EventBridge で AWS Transfer Family イベントをサブスクライブし、Amazon Simple Notice Service (SNS) を利用して通知を受け取ることもできます。

はい。事前設定済みのワークフロー検証ステップに対してファイル検証チェックが失敗した場合は、例外ハンドラーを使用してモニタリングシステムを呼び出したり、Amazon SNS トピック経由でチームメンバーに警告したりできます。

A: 有効にした各プロトコルに対して、サーバーエンドポイントを作成し構成してから削除するまでの間、1 時間単位で課金されます。また、SFTP、FTPS、または FTP サーバー経由でアップロードおよびダウンロードされたデータの量、AS2 経由で交換されたメッセージの数、および Decrypt ワークフローステップを使用して処理されたデータの量に基づいて請求されます。SFTP コネクタを使用する場合、転送されたデータ量とコネクタの呼び出しの数についての料金が請求されます。詳細については、料金のページをご覧ください。

いいえ。複数のプロトコルで同一のエンドポイントが有効であるか、プロトコルごとに異なるエンドポイントを使用しているかにかかわらず、有効にしたプロトコルごとの時間数と、各プロトコルを通じて転送されたデータ量に基づいて請求されます。

はい。サーバーの停止は料金には影響しません。これは停止にコンソールを使用した場合でも、CLI コマンド「stop-server」または API コマンド「StopServer」を実行した場合でも同様です。サーバーエンドポイントを作成しアクセスを構成してから削除するまでの間、各プロトコルに対して、1 時間単位で請求されます。

PGP キーを使用して復号するデータの量に基づいて、Decrypt ワークフローステップの料金が請求されます。マネージドワークフローを使用するためのその他の追加料金はありません。ワークフローの設定に応じて、Amazon S3、Amazon EFS、AWS Secrets Manager、AWS Lambda の使用についても課金されます。

いいえ。SFTP コネクタには時間単位の課金はありません。SFTP コネクタの料金の詳細については、料金ページをご覧ください。