cloud-sre

AWS S3 File Gateway 移行でユーザーのドライブ割り当てを壊さない方法

古い S3 File Gateway を置き換え、キャッシュを安全に作り直し、SSM State Manager で Windows ユーザーを移行する実践パターン。

Jun 12, 2026
AWSStorage GatewayWorkSpacesSSMmigration

AWS S3 File Gateway の置き換えは簡単に見えます。しかし、その gateway が多数の Windows デスクトップ向けに業務上重要な SMB ドライブを提供している場合、話は変わります。データの永続層は S3 でも、ユーザーは安定したドライブ文字、ディレクトリベース認証、ローカルキャッシュの挙動、予測可能な切り替えに依存しています。

この記事では、S3 データを維持したまま gateway appliance をクリーンに置き換え、AWS Systems Manager で Windows のドライブ再マッピングを自動化する移行パターンを説明します。

移行の目的

この環境には四つの要件がありました。

  • 旧 gateway のサポート期限前に置き換える
  • 既存の S3 object と SMB share 名を維持する
  • ユーザーに見えるドライブ文字を維持する
  • 各 Windows デスクトップを手作業で再設定しない

最終構成は次の形です。

Windows desktops
      |
      | SMB with directory-based authentication
      v
New S3 File Gateway
      |
      | Private VPC endpoints
      v
Existing S3 bucket

gateway instance と cache は置き換えました。S3 bucket は引き続き source of truth です。

まずロールバック経路を守る

旧 gateway を変更する前に、あとで復旧または説明できるだけの証跡を集めます。

  • gateway、SMB、file-share の設定をエクスポートする
  • アタッチ済み volume の delete-on-termination を無効化する
  • system volume と cache volume の snapshot を取得する
  • すべての snapshot 完了を待つ
  • CachePercentDirty が 0 になっていることを確認する

dirty cache の確認は、単なる running ステータスより重要です。cache がクリーンなら、まだ S3 に到達していないローカル書き込みが残っていないことを意味します。

古いディスクの再利用をやめた理由

初期案では、旧 system disk と cache disk を replacement EC2 instance にアタッチしました。ネットワーク経路は健全に見えました。期待する TCP port は接続を受け付けていました。しかし appliance は健全ではありませんでした。

  • activation endpoint が空の HTTP response を返す
  • ブラウザでは ERR_EMPTY_RESPONSE が表示される
  • SSH は server banner を返すが、key exchange 中に停止する

ここには重要な診断境界があります。

Open TCP port != healthy appliance service

古い boot disk の調査を続けると停止時間が延びますが、データ復旧の見通しは改善しません。永続ファイルはすでに S3 にあり、dirty cache も 0 だったため、クリーンな gateway deployment の方が低リスクでした。

同じ S3 データに対してクリーンな gateway を作る

成功した方法では、現行の Storage Gateway image と新しいローカルディスクを使いました。

  1. 新しい S3 File Gateway をデプロイする。
  2. 必要な public または VPC-hosted service endpoint 経由で接続する。
  3. 新しい cache storage を割り当てる。
  4. 既存の directory service に参加させる。
  5. 既存の S3 location を backing store とする SMB share を作成する。
  6. logging、alarm、IAM、security group、instance protection を再適用する。

S3 object を守るためにローカル cache をコピーする必要はありません。新しい gateway は、ファイルがアクセスされるたびに cache を再構築します。

SSM で Windows ドライブ移行を自動化する

AWS Systems Manager の command は SYSTEM として実行されます。一方、mapped network drive はユーザー session に属します。SYSTEM として net use を実行するだけでは、コマンド自体は成功しても、サインイン中のユーザーにはドライブが見えないことがあります。

信頼できるパターンは次の通りです。

  1. SSM State Manager で各 managed Windows node に PowerShell script を配置する。
  2. その script を HKLM Run entry に登録する。
  3. 実際のマッピングはユーザーのサインイン時に実行する。
  4. ログは保護された system directory ではなく、ユーザーの %LOCALAPPDATA% に書く。

ログイン script は保守的に動くべきです。

  • ドライブ文字が未使用なら、新しい share をマップする。
  • 旧 share を指しているなら置き換える。
  • ローカルディスクや無関係な network share なら何もしない。

これにより、移行 script が無関係なユーザー設定を上書きすることを防げます。

オフラインのデスクトップを正常な状態として扱う

State Manager association の実行時、多くの desktop node は停止している可能性があります。SSM はその target を Undeliverable と報告しますが、オフライン instance では想定内です。

scheduled association を使えば、デスクトップ起動後に設定が再試行されます。ユーザー向けの案内には次を含めます。

  • association interval に基づく現実的な反映時間
  • 期待される drive label と path
  • sign-out / sign-in のフォールバック
  • まだ失敗する場合に必要な実行時刻、スクリーンショット、ローカルログ

これにより、インフラの rollout をサポート可能なユーザー変更として扱えます。

完全な経路を検証する

gateway が RUNNING と表示されただけで終わりにしてはいけません。通常ユーザーのデスクトップから検証します。

echo gateway-test > E:\gateway-test.txt
type E:\gateway-test.txt
del E:\gateway-test.txt

あわせて次を確認します。

  • File Explorer に期待するドライブが表示される
  • 既存フォルダが見える
  • 作成、読み取り、更新、削除ができる
  • SMB session が新 gateway を指している
  • gateway と file-share のログにイベントが届いている
  • availability alarm と dirty-cache alarm が正常である

依存関係の順番で旧スタックを退役する

新しい経路を検証したら、旧リソースを管理された順序で削除します。

  1. 旧 SMB file share を、強制削除せずに削除する。
  2. 旧 gateway を削除する。
  3. 旧 EC2 instance を terminate する。
  4. 未アタッチの EBS volume を棚卸しする。
  5. 未使用で、必要な snapshot があることを確認できた volume だけ削除する。

新 gateway の active system volume と cache volume は、cleanup 対象から明示的に除外します。

再利用できる学び

  • S3 が永続データ層であり、dirty write が 0 なら gateway cache は置き換え可能。
  • ネットワーク到達性は application health ではない。
  • 古い boot disk を復旧するより、クリーンな appliance replacement の方が安全な場合がある。
  • ユーザーに見える drive mapping は user session で作成する必要がある。
  • SSM scheduled association は、断続的にオンラインになる desktop には一回限りの command より向いている。
  • 監視、ユーザーコミュニケーション、cleanup order は移行設計の一部であり、移行後の雑務ではない。