Amazon FSx for Windows File Server を共有 VPC にデプロイする

企業がアプリケーションフットプリントの多くをクラウドに移行し続けると、ファイルデータのためのソリューションが必要であることにすぐに気づきます。最近の多くのアプリケーションは、オブジェクトストア、NoSQL、グラフデータベースなどの API 駆動型ストレージサービスとインタラクションするように構築されていますが、ファイルサービスに依存するワークロードは依然として多数あります。多くの場合、これらのアプリケーションは、ファイルストレージソリューションの厳密な可用性の特性を必要とする一連の原則に基づいて設計されています。

前述の理由により、多くのお客様は、業界標準の SMB プロトコルでアクセスでき、回復力があり、スケーラブルで耐久性のある Windows ファイルストレージをアプリケーションに提供する簡単な方法として、Amazon FSx for Windows File Server (Amazon FSx) を利用しています。最近、Amazon FSx は、共有 Virtual Private Cloud (VPC) 環境のサポートを発表しました。これにより、お客様は、ローカルアカウント内で共有されるサブネットに直接ファイルシステムをデプロイできます。このタイプのパターンを採用すると、アプリケーション開発者は、職務の分離を通じて、セキュリティを維持しながらスピードを向上させることができます。基盤となるネットワークトポロジが組織のすべてのセキュリティ標準およびベストプラクティスを確実に満たすようにする作業を別のチームが行うことで、アプリケーション開発者は構築に集中できます。これらの利点については、以下で詳しく説明します。

このブログ投稿では、共有 VPC 環境での Amazon FSx のデプロイについて説明します。しかし、最初に、一部のお客様が共有 VPC の採用を決定した理由について少しお話ししましょう。

お客様が共有 VPC を使用している理由

多くの AWS のお客様は、ワークロードの分離を提供するために複数のアカウントを使用しています。アプリケーションごとに 1 つのアカウントをプロビジョニングすることから、アーキテクチャパターンまたは分類によってアプリケーションをグループ化することまで、ワークロードをアカウントにマッピングするためにお客様が使用できる多くの戦略があります。これらのアカウントを大規模に管理するには、多くの場合 AWS Organizations を使用する必要があります。Organizations は AWS Resource Access Manager (AW​​S RAM) と統合され、お客様は、他の AWS アカウントと多数のサービス (VPC サブネットなど) を共有し、単一のロケーションからその共有を制御できます。

一部のお客様は、アカウントベースのワークロード分離の提供を超えて、ネットワークトポロジの定義を別のチームに委任することにより、ネットワークの責任を一元化したいと考えています。このお客様は、ネットワークとアプリケーションインフラストラクチャを取り巻く職務の分離を、最小権限を強制するための別の方法とみなしています。お客様によっては、共有 VPC が魅力的なオプションとなる場合があります。共有 VPC を使用すると、VPC サブネットを他のアカウントと共有するメカニズムを提供することで、VPC を従来のアカウントの境界を超えて拡張できます。AWS アカウントは、ローカル VPC 内から一連のサブネットをプロビジョニングし、これらのサブネットを 2 番目のアカウントと共有できます。次に、VPC 共有参加者と呼ばれるその 2 番目のアカウントは、AWS リソースを VPC にプロビジョニングできます。VPC の所有者はネットワークトポロジのコントロールを維持し、VPC の参加者はその共有ネットワーク内でプロビジョニングするリソースを所有します。

共有 VPC とファイルサービス

では、SMB ベースの Windows アプリケーションとワークロードに Windows ファイルサービスが必要な場合は、どうすればよいでしょうか。 既に述べたように、最近、Amazon FSx は、共有 VPC へのデプロイのサポートを発表しました。このブログ投稿では、これらの環境の 1 つへのデプロイについて説明します。

この環境は、単一の AWS Organization にグループ化された次のアカウントで構成されています。

1. 複数の組織アカウント間での共有を可能にするOrganizations のマスターアカウント。
2. Microsoft Active Directory 環境をホストする共有 ID アカウント。
3. 共有 VPC をホストするネットワークサービスアカウント。
4. VPC 参加者アカウント。共有サブネットを消費し、Amazon FSx for Windows ファイルサーバーファイルシステムのデプロイに使用されます。

定義されたアーキテクチャは、次の図に示されています。

このブログ投稿では、次の手順について説明します。

1. 必要な AWS Organizations の依存関係の設定
2. Amazon FSx VPC サブネットの作成および共有
3. AWS が管理する Microsoft Active Directory 環境のアプリケーションアカウントとの共有
4. 共有サブネットでの Amazon FSx for Windows ファイルサーバーのプロビジョニング

注意: Amazon FSx は、Windows ファイルサービスをプロビジョニングおよび利用する方法に関して、非常に高い柔軟性をお客様に提供します。このブログは共有 VPC サブネットへのデプロイに重点を置いていますが、お客様は代わりに Amazon FSx を非共有サブネットにデプロイすることもできます。続いて、共有サブネットにプロビジョニングし、リモートアカウントが当該サブネットを使用して、それらのファイル共有をマウントするリソースをデプロイするようにできます。

AWS Organizations 内での Resource Access Manager の有効化

AWS Organizations は、他の組織アカウントが AWS RAM を使用してリソースを共有できるように設定する必要があります。この承認は、Organizations のマスターアカウント内で行われます。Organization のマスターアカウントで AWS RAM が有効になっていることを確認します。

次に、Organizations のマスターアカウント内で、[AWS Organization 内で共有を有効にする] が選択されていることを確認する必要があります。選択されていない場合は、このオプションをオンにして [保存] を選択します。

Organization を構成するアカウント間でサブネットリソースを共有するには、これらのオプションが両方とも必要です。これが完了すると、サブネットを作成して AWS RAM 経由で共有できるようになります。

共有 VPC 環境の構築

ネットワークサービスアカウントから、2 つのアベイラビリティーゾーンにまたがる 2 つのサブネットを持つ単一の VPC を構築して、回復力を確保します。これらのサブネットは、FSx for Windows ファイルサーバーのデプロイで使用されるアプリケーションアカウントと共有されます。

VPC とサブネットが作成されたら、リソース共有を作成できます。AWS RAM 内で、タイプをサブネットとする新しいリソース共有を作成します。Amazon FSx のデプロイで使用される 2 つのサブネットを選択し、関連付けられたプリンシパルとしてアプリケーションアカウントのアカウント ID を追加します。リソース共有が作成されると、2 つのサブネットがアプリケーションアカウントと共有され、共有リソースの下に次のように表示されます。

リソース共有には受信者からの確認が必要なため、アプリケーション内の AWS RAM の「共有」セクションから共有を受け入れます。

これで、操作可能な共有 VPC 環境ができました! ただし、FSx for Windows ファイルサーバーリソースのデプロイを開始する前に、Microsoft Active Directory 環境を設定して共有する必要があります。

Microsoft Active Directory 環境の共有

AWS が管理する Microsoft Active Directory 環境はすでに共有 ID アカウントにデプロイされているので、少し先にスキップします。AWS Managed Microsoft AD により、ユーザーは他の AWS アカウントと Active Directory 環境を共有できます。つまり、リモートアカウントに配置されたリソースに必要なアクセス権を提供しつつ、集中管理されたアカウントで AD 環境をデプロイできます。これらのリソースの中には、Windows ベースの EC2 インスタンスまたは Amazon FSx ファイル共有があります。ID サービスを別のアカウントにデプロイすると、ID サービスと他の場所で提供されるサービスとの間にアカウントレベルの分離を強制できます。このブログでは、ID 管理を共有 ID アカウントに一元化しましたが、Amazon FSx は、オンプレミスのセルフマネージド Active Directory 環境と直接統合することにも留意してください。

ただし、ディレクトリを共有する前に、まず VPC ホスティングディレクトリサービスとそれを使用する VPC の間にネットワーク接続があることを確認する必要があります。この環境では、これが ID VPC とネットワークサービス VPC です。これらの要件の詳細については、このドキュメントを参照してください。

すでにこれらの VPC 間のピアリング関係を設定してあるので、次のステップでは、アプリケーションアカウントとディレクトリを共有します。2 つの VPC をピアリングすることにしましたが、要件はネットワーク接続であるため、任意のネットワークパスで十分です (これには AWS Transit Gateway が含まれます)。また、Amazon FSx を VPC 参加者アカウントにデプロイしているため、共有サブネットにデプロイされたすべてのリソースは、ネットワークサービスの VPC ピアリング接続を活用できます。これにより、サブネットに適切なルートが提供されます。

[ディレクトリサービス] ページの [ディレクトリ] メニューリンクからディレクトリ ID を選択し、トップメニューから [アクション] → [ディレクトリを共有] を選択します。ネットワークサービスアカウントは Organizations のマスターアカウントではないため、「このディレクトリを組織内の AWS アカウントと共有する」はグレー表示されます。アカウント ID を指定して [共有] を選択することにより、ディレクトリをアプリケーションアカウントと直接共有します。

ターゲットアカウント内で、Active Directory 環境が [ディレクトリサービス] 画面の [共有ディレクトリ] に表示されます。 この手順が完了すると、共有 VPC 環境に FSx for Windows ファイルサーバーをデプロイする準備が整います。

共有サブネットでの FSx for Windows ファイルサーバーのデプロイ

最後の手順は、アプリケーションアカウント内で行います。

デプロイを開始する前に、まずインフラストラクチャのセキュリティグループを作成する必要があります。このセキュリティグループはアプリケーションアカウント内に作成され、共有 VPC を参照します。このドキュメントから必要な受信/送信ポートを追加します。

セキュリティグループが作成されたら、デプロイを開始する準備が整います。Amazon FSx サービス画面から、以下を実行します。

1. [ファイルシステムの作成] を選択します。
2. Amazon FSx オプションを選択し、[次へ] を選択します。
3. [ファイルシステムの作成] 画面で、次の情報を入力します。
   • 名前、ストレージ容量、スループット容量を指定して、[ファイルシステムの詳細] セクションに入力します。ファイルシステムの可用性を高めるため、マルチ AZ を選択したままにします。
   • [ネットワークとセキュリティ] セクションから、共有 VPC の ID を選択し、2 つの共有サブネットを選択します。1 つは優先用、もう 1 つはスタンバイ用です。上記で作成したセキュリティグループを選択します。
4. Windows 認証セクションから共有 Microsoft Active Directory 環境を選択します。
5. [暗号化] とその他のセクションはデフォルトのままにし、[次へ] を選択します。
6. オプションを確認し、[ファイルシステムの作成] を選択します。

これで完了です! ファイルシステムの作成が完了したら、ファイルシステム名を選択し、[ネットワークとセキュリティ] タブから VPC サブネットのロケーション情報を確認します。

クリーンアップ

ここで、デプロイしたリソースを削除します。共有 ID アカウントから既存の Active Directory 環境を利用したため、ネットワークサービスとアプリケーションアカウントの当該リソースの削除に焦点を当てます。

アプリケーションアカウントから次の手順を実行します。

1. Amazon FSx ファイルシステムを削除する
   • Amazon FSx 画面から、新しく作成した Windows ファイルシステムの名前を選択し、[アクション] を選択して、[ファイルシステムの削除] を選択します。
     • これはデモなので、最終的なバックアップは作成しません。このプロセスには数分かかる場合があります。
   • Amazon FSx ファイルシステムで使用されているセキュリティグループを削除する
   • 共有 Microsoft Active Directory を削除する
     • [ディレクトリサービス] 画面の [共有ディレクトリ] で、共有ディレクトリを選択し、[削除] を選択します。
2. ネットワークサービスアカウントから以下の手順を実行します。
   • 共有 VPC サブネットを削除する
   • 共有 VPC を削除する

まとめ

Organization 内で、リソース共有を有効にし、VPC を構築し、アプリケーションアカウントと 2 つのサブネットを共有し、Microsoft Active Directory 環境を共有し、最後に FSx for Windows ファイルサーバーを共有 VPC サブネットにデプロイしました。これで、ネットワークサービスチームが基盤となるネットワークトポロジのコントロールを維持しながら、アプリケーションチームが SMB ワークロード用のファイル共有をプロビジョニングできるようになりました。なぜこれが有益なのでしょうか。 その理由はシンプルです。これにより、アプリケーション開発者は安全を確保しながら高速で移動できます。開発者は、ネットワーク通信やネットワークセキュリティの複雑さに意識を集中する必要がなくなり、構築に集中できます。

最後に、まとめとしていくつか考えてみましょう。まず、複数の VPC を使用したアプリケーションの分離がますます一般的になっています。共有 VPC に移行するお客様は、共有サブネットにデプロイしてアカウントスコープの Amazon FSx 環境を作成することで、職務の分離を強化できます。

そして最後に、Amazon FSx はファイル共有にアクセスするためのさまざまな方法をサポートしており、今日の説明は概括的なものにとどまります。ファイル共有には、アカウント、AWS リージョン、オンプレミスクライアントなど、さまざまな場所からアクセスすることもできます。Amazon FSx は、Linux または macOS を介したファイル共有へのアクセスもサポートしています。さまざまなタイプのアクセス方法の詳細については、このドキュメントを参照してください。

FSx for Windows ファイルサーバーを共有 VPC 環境にデプロイするプロセスについてお読みいただきありがとうございました。さらに質問がある場合は、以下のコメントセクションからフィードバックをお寄せください。