创建AWS CloudFormation模板实现EBS卷挂载Windows EC2并分区的技术求助

Alright, let's break this down into actionable steps. I’ve built similar Windows EC2 + EBS setups with CloudFormation before, so I’ll walk you through creating the volume, attaching it, and automating that tricky DISKPART configuration—plus fix the issues you’re hitting with running DISKPART.

First, here’s a template that creates an EBS volume and attaches it to your existing Windows EC2 instance. We’ll add parameters so you can customize the volume specs and target instance.

AWSTemplateFormatVersion: '2010-09-09'
Parameters:
  TargetEC2InstanceId:
    Type: String
    Description: ID of your existing Windows EC2 instance
  EBSVolumeSize:
    Type: Number
    Default: 50
    Description: Size of the EBS volume in GB
  EBSVolumeType:
    Type: String
    Default: gp3
    AllowedValues: [gp2, gp3, io1, io2, st1, sc1]
    Description: Type of EBS volume
  DriveLetter:
    Type: String
    Default: D
    Description: Drive letter to assign (must be unused on the instance)
  AvailabilityZone:
    Type: String
    Description: AZ matching your EC2 instance (e.g., us-east-1a)

Resources:
  # Create the EBS Volume
  DataEBSVolume:
    Type: AWS::EC2::Volume
    Properties:
      Size: !Ref EBSVolumeSize
      VolumeType: !Ref EBSVolumeType
      AvailabilityZone: !Ref AvailabilityZone
      Tags:
        - Key: Name
          Value: DataVolume-AttachedTo-!Ref TargetEC2InstanceId

  # Attach the volume to the EC2 instance
  VolumeAttachment:
    Type: AWS::EC2::VolumeAttachment
    Properties:
      InstanceId: !Ref TargetEC2InstanceId
      VolumeId: !Ref DataEBSVolume
      Device: xvdf  # Windows maps xvdf to Disk 1 (adjust if needed, but xvdf is safe for secondary volumes)
    DependsOn: DataEBSVolume

  # SSM Document to run DISKPART configuration
  DiskConfigSSMDocument:
    Type: AWS::SSM::Document
    Properties:
      Content:
        schemaVersion: '2.2'
        description: Configure attached EBS volume with partition and drive letter
        mainSteps:
          - action: aws:runPowerShellScript
            name: ConfigureDisk
            inputs:
              runCommand:
                - |
                  $scriptPath = "C:\diskconfig.txt"
                  @"
                  rescan
                  select disk 1
                  online disk
                  convert gpt
                  create partition primary
                  format fs=ntfs quick label="DataDrive"
                  assign letter=$($DriveLetter)
                  exit
                  "@ | Out-File -FilePath $scriptPath -Encoding ASCII
                  diskpart /s $scriptPath

  # Associate the SSM Document with your EC2 instance to run the config
  DiskConfigAssociation:
    Type: AWS::SSM::Association
    Properties:
      Name: !Ref DiskConfigSSMDocument
      Targets:
        - Key: InstanceIds
          Values: [!Ref TargetEC2InstanceId]
      WaitForSuccessTimeoutSeconds: 300
    DependsOn: VolumeAttachment

I’ve run into the same DISKPART headaches on Windows EC2 instances—here’s why you might be struggling and how to fix it:

Common Problem 1: Disk isn’t showing up in DISKPART #

When you attach an EBS volume, Windows doesn’t automatically detect it. The fix? Add a rescan command at the start of your DISKPART script (like in the template above). This forces Windows to scan for new disks before trying to configure them.

Common Problem 2: Permission errors running DISKPART #

DISKPART requires admin privileges. If you’re running it via Remote Desktop, make sure you launch Command Prompt as Administrator. If you’re automating it (like with SSM), the SSM Agent runs as the SYSTEM account, which has full admin rights—so no issues there.

Common Problem 3: Drive letter is already in use #

If your target drive letter is taken, the assign command will fail. To avoid this:

• Check existing drive letters first with wmic logicaldisk get caption
• Use a parameter in your CloudFormation template (like DriveLetter) so you can specify an unused letter upfront
• Add error handling in the PowerShell script to pick an alternative if the desired letter is taken

Why SSM Run Command is better than manual DISKPART #

Instead of RDPing into the instance to run DISKPART, using SSM Run Command lets you automate the entire process from CloudFormation. It’s more reliable, doesn’t require opening RDP ports, and you can track execution status directly in the AWS Console.

Prerequisite for SSM #

Make sure your EC2 instance has:

• The SSM Agent installed (Windows AMIs from AWS have this by default)
• An IAM role attached with the AmazonSSMManagedInstanceCore policy (grants permissions for SSM to interact with the instance)

After deploying the CloudFormation stack:

1. Go to the AWS Systems Manager Console → Run Command → Check the status of the association
2. If successful, RDP into your instance and verify the new drive appears in File Explorer
3. If it fails, check the SSM logs (under Instance Details → SSM Agent Logs) to debug issues like disk number conflicts or drive letter clashes

内容的提问来源于stack exchange，提问作者Sudheesh Sudhakaran