Migrate gp2 EBS Volumes to gp3 with Matched Performance Settings

Overview

Migrate gp2 EBS volumes to gp3 while preserving or improving performance and reducing storage costs. The plan first discovers where gp2 is used across volumes, instances, and Auto Scaling constructs, then lets you choose what to migrate. It calculates equivalent gp3 performance settings where needed, applies changes to live volumes and launch definitions, tags migrated resources, and finally validates that all targeted workloads are running on gp3 with expected performance.

Execution Details

Assessment

This phase identifies all gp2 usage and its impact so you can decide what to migrate.

Inventory gp2 EBS volumes

• Enumerate in-scope AWS regions and list EBS volumes, filtering to type gp2.
• Capture technical and status details for each gp2 volume, including:
  • Volume attributes: ID, region/AZ, type, size (GiB), IOPS, throughput (if reported).
  • State details: volume state, attachment state, and any ongoing modification.
  • Role: whether each volume is root/boot or data-only, based on device names and instance block device mappings.
• Determine if each volume is using only baseline gp2 performance or has non-default/heightened performance needs.
• Store results in a structured inventory (e.g., table/spreadsheet) and confirm coverage of all in-scope gp2 volumes.

Map gp2 volumes to EC2 instances and Auto Scaling

• For each gp2 volume, gather all attachments:
  • Instance ID, device name, attachment state.
• For each attached instance, collect:
  • Name tag (if any), instance state, instance type, and AZ.
• Determine whether each instance is part of an Auto Scaling group (ASG) and record:
  • ASG name and any associated launch template or launch configuration.
• Flag unattached gp2 volumes and capture key tags (application, environment, owner).
• Consolidate the volume-to-instance-to-ASG mapping with the inventory to understand operational impact and help prioritize migration.

Identify launch templates using gp2

• Enumerate EC2 launch templates and identify relevant versions:
  • At minimum the default version and any versions used by ASGs or other services.
• Inspect block device mappings for each relevant version:
  • Record details where the EBS type is gp2 (template name, version, device name, size, IOPS, throughput if specified).
• Flag all template versions that use gp2 as migration candidates, including ones that rely on gp2 via defaults if they are in scope.
• Link templates to any associated ASGs or consuming services, and produce a consolidated list of gp2-based launch template versions.

Identify launch configurations using gp2

• Enumerate Auto Scaling launch configurations in scope.
• Inspect their block device mappings and record those using gp2:
  • Launch configuration name, device names, size, IOPS and throughput (if specified).
• Mark all such launch configurations as candidates for gp3 migration, including those implicitly using gp2 defaults if relevant.
• Map each gp2-based launch configuration to the ASGs that use it and compile a consolidated list for the configuration phase.

User selection of migration targets

• Present the full gp2 inventory and mappings so you can:
  • Review volume size and performance characteristics, attachment state, and whether volumes are root or data-only.
  • Understand which instances and ASGs are affected by each gp2 volume.
  • Review launch templates/versions and launch configurations that define gp2 volumes and what they support.
• Guide you through deciding, for each item, whether it is:
  • In scope for migration to gp3, or excluded (e.g., nearing decommission, special requirements).
• Capture:
  • Which volumes, launch template versions, and launch configurations will be migrated.
  • Priority and sequencing (e.g., non‑prod before prod, critical vs. non‑critical).
  • Any constraints such as maintenance windows or approval requirements.
• Produce an approved, structured list of gp2 resources to be migrated that downstream tasks will consume.

Configuration

This phase translates gp2 performance to gp3 settings, performs the migrations, and updates launch definitions.

Determine equivalent gp3 performance settings

• Use the approved list of gp2 volumes from the assessment phase.
• For each selected volume, review its size, IOPS, and throughput.
• Separate volumes into:
  • Those using only baseline gp2 performance (no special IOPS/throughput needs), which will use gp3 defaults.
  • Those with effective performance requirements above gp2 baseline.
• For volumes with elevated needs:
  • Calculate target gp3 IOPS and throughput that meet or exceed current behavior within gp3 limits.
  • Validate calculations against gp3 constraints for the given size and adjust where needed.
  • Document any cases where gp2 characteristics cannot be matched exactly and note chosen gp3 settings or alternative approaches.
• Produce and store a mapping per volume from existing gp2 characteristics to planned gp3 size/IOPS/throughput for later use.

Modify EBS volumes to gp3

• Retrieve the approved volumes and any calculated gp3 performance settings.
• Confirm each volume is in a modifiable state and not already undergoing conflicting changes.
• Define, for each in-scope volume:
  • A simple type change to gp3 using default performance where no custom settings are required.
  • A gp3 configuration including explicit IOPS and throughput for volumes with calculated targets.
• Apply modifications, ensuring size is not reduced and IOPS/throughput stay within gp3 limits.
• Monitor progress until modifications complete and identify any failures or non-optimal states with error details.
• After completion:
  • Re‑query volume attributes and record final type, size, IOPS, and throughput.
  • Save a before/after inventory of all migrated volumes.

Update launch templates to gp3

• Take the in-scope launch templates and versions that currently use gp2.
• For each targeted version:
  • Identify block device mappings with gp2 volumes.
  • Decide whether to modify an existing version (where appropriate) or create a new gp3-based version according to your versioning practices.
• For each affected mapping:
  • Change volume type from gp2 to gp3.
  • Apply explicit gp3 IOPS/throughput only where prior gp2 configurations or patterns required explicit performance; otherwise use gp3 defaults.
• Validate each updated or new version to ensure:
  • Device names, sizes, encryption, and other settings remain correct aside from the deliberate switch to gp3 (and any new performance values).
• Record any ASGs or other consumers that should later be pointed to the updated versions.
• Summarize changes per template: original version and settings, new version (if created), and resulting gp3 configuration.

Update launch configurations to gp3

• Use the list of in-scope gp2-based launch configurations.
• For each:
  • Identify all gp2 block device mappings.
  • Define a new launch configuration that:
    • Preserves non-storage settings (AMI, instance type, security groups, key pair, user data, etc.) unless changes are explicitly required.
    • Converts gp2 EBS mappings to gp3.
  • Apply explicit gp3 IOPS/throughput only where the original gp2 configuration had explicit performance settings; otherwise rely on gp3 defaults.
• Validate new launch configurations to ensure block device mappings, volume sizes, and encryption mirror the originals, aside from the intended gp3 changes.
• Document the mapping from each original gp2-based launch configuration to its gp3-based replacement for use when updating ASGs.
• Produce a summary listing old vs. new configurations and volume details.

Tag migrated volumes

• Retrieve the final list of volumes successfully migrated from gp2 to gp3.
• Confirm or define tagging standards for migration, such as:
  • Migration status, migration date/time, project or owner, and optionally source volume type or migration wave.
• For each migrated volume:
  • Review existing tags to avoid overwriting critical information.
  • Apply or update migration-related tags to indicate the gp2→gp3 migration and relevant metadata.
• Capture any tagging failures and either retry or log them for later remediation.
• Generate a report of all migrated volumes and their new/updated tags to confirm consistent tagging.

Validation

This phase confirms that volumes and new instances are using gp3 as intended and that performance remains acceptable.

Confirm migrated volumes and performance settings

• Use the list of targeted volumes along with their recorded pre‑migration type and performance.
• For each volume:
  • Verify the current type is gp3.
  • Ensure size is at least as large as before, with no reductions.
• For volumes with explicit performance requirements:
  • Compare current IOPS and throughput to planned gp3 settings and original effective gp2 behavior to ensure they meet or exceed previous characteristics within service constraints.
• For volumes that relied only on baseline gp2:
  • Confirm type is gp3 and that each volume is in a healthy state without error or adverse modification status.
• Identify and document any discrepancies in type, size, IOPS, or throughput for follow-up.
• Produce a validation report summarizing pre‑ and post‑migration characteristics and highlighting any volumes needing remediation.

Verify new instances use gp3

• Retrieve the updated launch template versions and new gp3-based launch configurations.
• Where practical, perform test launches in non‑production or controlled environments:
  • Launch instances from updated launch templates and inspect their attached volumes.
  • Confirm all EBS volumes are type gp3 with expected size and, where applicable, expected IOPS/throughput.
• For ASGs updated to use new gp3-based definitions:
  • Allow one or more instances to launch through normal scaling or controlled tests.
  • Verify attached volumes use gp3 with expected settings.
• Flag any new instances that still use gp2 despite supposed updates and investigate likely causes (e.g., outdated template versions still referenced).
• Record results to confirm that new instances from updated definitions are consistently using gp3 or to document exceptions that require remediation.

Monitor EBS and EC2 performance post‑migration

• Clearly identify the set of instances and EBS volumes impacted by the migration for monitoring.
• Determine relevant CloudWatch metrics for the migrated volumes and associated instances, such as:
  • For EBS: read/write operations and bytes, latency-related metrics, queue length, and any burst or gp3‑specific indicators.
  • For EC2: CPU utilization, disk-related metrics (if collected), and health/status checks.
• Define an appropriate monitoring window that reflects typical workload patterns.
• During this window, review metrics to:
  • Compare performance to expected or historical baselines.
  • Detect any increased latency, sustained high queue depth, or other signs of throttling or degradation.
• Flag and document any workloads with apparent performance regressions, including IDs, time ranges, and observed metrics.
• Summarize findings, noting whether any material performance issues were observed after migrating from gp2 to gp3 and listing any items needing further tuning or investigation.