ソリューションアーキテクトは、Windows Server の Amazon EC2 インスタンスで動く業務システム向けに、部門ごとの共有フォルダを AWS 上へ新しく用意します。利用者は既存の Active Directory のアカウントで認証し、端末からドライブとして割り当てて使います。共有するのは容量の小さい一般的な文書です。 最小限の運用上のオーバーヘッドで、これらの要件を満たすソリューションはどれですか。
Windows と Active Directory を前提とした共有フォルダの置き場所を選ぶ
Amazon FSx for Windows File Server を作成し、部門ごとの共有フォルダを置く。
Amazon FSx for Windows File Server は、SMB（Windows が標準で使うファイル共有のプロトコル）で接続する、Windows 向けのフルマネージドな共有ファイルストレージです。ファイルシステムを Active Directory に参加させられるので、利用者は今使っているアカウントのまま認証でき、別の認証の仕組みを用意する必要がありません。
端末からは共有のパスをドライブとして割り当てて使えるため、利用者の使い方も既存のアプリケーションが指定するパスの形式も変わりません。部門ごとの共有は、同じファイルシステムの中にフォルダを分け、フォルダごとに Windows のアクセス許可を設定すれば実現できます。
Amazon EFS のファイルシステムを作成し、各 Windows インスタンスからマウントする。
Amazon EFS はフルマネージドなファイルストレージで、共有フォルダを持たせたいという発想には合っています。接続には、NFS（ネットワーク越しにファイルシステムを共有する仕組み）を使います。
しかし Windows ベースの Amazon EC2 インスタンスでの利用はサポートされておらず、共有元が Windows Server である本問はこの 1 点で成立しません。Active Directory に参加して既存のアカウントで認証する受け皿も持たないため、認証の仕組みを別に用意することになります。
Amazon S3 バケットを作成し、部門ごとのプレフィックスに文書を保管する。
Amazon S3 はオブジェクトストレージで、プレフィックスでフォルダのような階層を表現できます。容量の心配がなく、文書の保管先としては安価で耐久性も高い選択です。
ただし S3 は HTTP の API でオブジェクト単位に読み書きするサービスで、端末からドライブとして割り当てられるファイルシステムではありません。利用者は専用の画面や API を使うことになり、認証も Active Directory ではなく IAM の側で組み直すことになります。
ファイルサーバー役の EC2 インスタンスに Amazon EBS ボリュームをアタッチして共有する。
EC2 インスタンスに Amazon EBS ボリュームを付け、Windows のファイルサーバーとして構成すれば、SMB での共有も Active Directory への参加も実現できます。オンプレミスと同じ作り方なので、実際に動く構成です。
ただしこの構成では、OS のパッチ適用・容量の拡張・障害時の切り替えを自分で受け持つことになります。マネージドサービスなら AWS 側が担う運用を自社で抱えることになり、運用上のオーバーヘッドを最小にするという条件で劣ります。
共有ファイルストレージの選定でまず見るのは、使う側が何で、どのプロトコルで接続するかです。
・Amazon FSx for Windows File Server — SMB で接続する Windows 向けの共有です。
Active Directory に参加させられるので、利用者は今のアカウントのまま認証でき、ドライブとして割り当てて使えます。問題文に Windows・Active Directory・SMB・ドライブの割り当てが出たら、まずここです。
・Amazon EFS — NFS の共有です。Windows ベースの EC2 インスタンスでの利用はサポートされないのが分かれ目です。
「複数から同時に読み書き」だけで飛びつかず、使う側が Windows か Linux かを確認します。
・EC2 に自前のファイルサーバー — 要件だけなら成立しますが、OS のパッチ適用・容量の拡張・障害時の切り替えを自分で受け持つことになります。新しく用意する場面では、まずマネージドサービスで満たせないかを確認します。