医療情報システム企業が、オンプレミスのSFTPサーバーをAWSへ移行しようとしています。このSFTPサーバーは50の病院パートナーとHL7形式（Health Level 7：医療情報交換規格）の臨床データファイルを交換するために使用されています。 【現在の構成】 ・SFTPサーバーのホスト名：sftp.medcomp.example.com（DNS管理は自社） ・認証方式：各病院パートナーごとにSSH公開鍵認証（50個の異なる公開鍵） ・サーバーのSSHホスト鍵：既知のフィンガープリントがパートナーのknown_hostsファイルに登録済み ・ファイル格納先：ローカルストレージ（/data/sftp/） 【要件】 ・50の病院パートナーはSFTPクライアントの設定を一切変更しない（同じホスト名・ポート22・SSH鍵をそのまま使用、known_hostsの更新も不可） ・ファイルはAmazon S3に格納する ・ファイルアップロード時にHL7処理用Lambda関数を自動トリガーする ・移行中のダウンタイムはゼロ（DNS切り替え時も含む） これらの要件をすべて満たすために実施すべき作業を2つ選んでください。（2つ選択）
正解： A: AWS Transfer Family でSFTPサーバーを作成する際、オンプレミスSFTPサーバーの既存SSHホスト鍵（秘密鍵）をTransfer Familyにインポートする。各病院パートナーの50個のSSH公開鍵もユーザーごとにインポートし、Amazon S3バケットをストレージバックエンドに設定する。切り替え直前にDNS（sftp.medcomp.example.com）のTTLを短縮し、Transfer FamilyエンドポイントのDNS名に切り替える。 B: AWS Transfer Familyのマネージドワークフロー（Managed Workflows）機能を使用して、ファイルアップロード完了後に自動的にHL7処理用Lambda関数をトリガーするワークフローステップを設定する。 AWS Transfer Familyは既存のSSHホスト鍵（秘密鍵）をインポートする機能をサポートしています。これにより新サーバーが同じホストキーフィンガープリントを提示するため、パートナーのknown_hostsを更新する必要がありません。さらに各ユーザーのSSH公開鍵もインポート可能で、パートナー側の鍵変更も不要です。S3バックエンドをネイティブサポートし、DNS切り替え前にTTLを短縮することでダウンタイムを最小化できます。Transfer Familyのマネージドワークフロー機能は、ファイルアップロード後の処理（Lambda呼び出し・タグ付け・コピーなど）をノーコードで設定できます。S3イベント通知でも同様の動作は可能ですが、Transfer Familyのワークフローはアップロード完了を確実に検出してから実行するため、より信頼性が高いです。 選択肢Cは DataSyncはSFTPエンドポイントの置き換えではなくデータ同期ツールです。移行完了までパートナーはオンプレミスサーバーに接続し続けることになり、根本的な解決になりません。 選択肢Dは S3 Fuseマウントはパフォーマンスと信頼性の問題があり本番環境には不適切です。またEC2インスタンスの管理が必要となりマネージドサービスの利点がありません。 選択肢Eは新しいSSHホストキーを使用した場合、パートナーにknown_hostsの更新を依頼することは「クライアント設定の変更ゼロ」という要件に直接違反します。Transfer Familyの既存ホスト鍵インポート機能を活用すべきです。