AMI より起動した Windows OS の EC2インスタンスで以前と異なるドライブレターマッピングになる原因を教えてください
2025.01.28困っていること
EBS が複数アタッチしている構成の AMI を利用して、Nitro 世代のインスタンスタイプで Windows EC2 インスタンスを起動しました。
調査したところ、同様の AMI で起動した他 Windows EC2インスタンスと異なるドライブレターのマッピング構成でした。原因を教えてください。
（例: xvdf が F ドライブとして認識される想定が、D ドライブとして認識されていた）
どう対応すればいいの?
デバイス（EBS）が応答する順序に基づいてマッピングされます。そのため AWS の仕様上、異なるドライブレターのマッピング構成になり得ます。
インスタンスのブート時にアタッチ済みのデバイスを検出し、そのデバイスがブロックデバイスマッピングでどのように指定されているかではなく、デバイスが応答する順序に基づいてデバイスノードを作成します。
現時点 AWS 側において自動で制御するような直接的な機能やサービス提供は存在しないため、希望するドライブレターをマッピングしたい場合には、ユーザーデータ利用が考えられます。
ディスク番号とデバイス名 (xvdg など) を取得し、その情報をもとに希望されるドライブレターを割り当てていただくスクリプト作成をご検討ください。
補足
Windows OS の例で紹介しているものの、Linux OS でも同様の事象が発生します。
Linux では、NVMe デバイス名はパターン に従います。ここで/dev/nvme<x>n<y>、<x> は列挙順序で、EBS の場合、<y> は 1 です。場合によっては、デバイスは後続のインスタンスの開始時に異なる順序で検出に応答することがあり、デバイス名が変更されます。また、ブロックデバイスドライバーによって割り当てられるデバイス名は、ブロックデバイスマッピングで指定される名前と異なる場合があります。
![[AWS CDK] CloudFrontの標準ログV2をL1 Constructで設定してみたかった](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f66629e23bafcf47fa6477fd0349a4f7/3e371b05917375d87daf613d54a600d8/amazon-cloudfront)
![[アップデート]AWS Healthの通知の管理を簡素化する「AWS管理通知」機能がGAされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-cd6bca3e0ea12bce10d34b5c73117202/e7dcb00f209227795370c8effc01051d/aws-eyecatch.png)
