EBS, Volume Types, and Why gp3 Over gp2

• EBS (Elastic Block Store) – a durable, network-attached block storage service for EC2 instances that behaves like a virtual hard disk and persists independently of the instance lifecycle.
• gp2 and gp3 – general-purpose SSD volume types suitable for most workloads such as boot volumes and medium databases.
• io1 and io2 – provisioned-IOPS SSD types for the highest, most consistent low-latency performance, used for critical transactional databases.
• st1 (throughput-optimized) and sc1 (cold) – HDD types designed for large, sequential workloads at low cost; they cannot serve as boot volumes.
• gp3 advantage – decouples IOPS and throughput from volume size and is roughly twenty percent cheaper per GiB than gp2.

What is EBS?

EBS (Elastic Block Store) provides durable, network-attached block storage volumes for EC2 instances. The operating system formats it with a filesystem and uses it like a local disk, but the storage lives separately from the physical host and is replicated within an Availability Zone for durability. The key property is persistence: if an instance is stopped or even terminated (when the volume is not set to delete on termination), the EBS volume and its data survive and can be re-attached to another instance.

// Conceptual model of an EBS volume attachment
package com.bank.infrastructure;

public class EbsVolume {
    private final String volumeId;
    private final String volumeType;  // gp3, gp2, io2, io1, st1, sc1
    private final int sizeGiB;
    private final String availabilityZone;
    private boolean attached;

    public EbsVolume(String volumeId, String volumeType, int sizeGiB, String az) {
        this.volumeId = volumeId;
        this.volumeType = volumeType;
        this.sizeGiB = sizeGiB;
        this.availabilityZone = az;
        this.attached = false;
    }

    public void attachTo(String instanceId) {
        // Volume persists even when detached
        this.attached = true;
        System.out.println("Volume " + volumeId + " attached to " + instanceId);
    }
}

Why does EBS exist and why do we need different volume types?

EC2 instance store (ephemeral storage) is lost when an instance stops, which is unacceptable for persistent data like a banking database or application logs. EBS gives you durable storage that survives instance lifecycle events. Different volume types exist because workloads have different performance and cost profiles. A boot volume for an internal tool has different needs than the core banking ledger, and paying io2 prices for a log volume would waste money.

// Matching volume type to workload
package com.bank.infrastructure;

import java.util.Map;

public class VolumeSelector {
    private static final Map<String, String> WORKLOAD_TO_TYPE = Map.of(
        "boot-volume",       "gp3",
        "medium-database",   "gp3",
        "core-ledger-db",    "io2",
        "log-archive",       "st1",
        "cold-compliance",   "sc1"
    );

    public static String recommend(String workload) {
        return WORKLOAD_TO_TYPE.getOrDefault(workload, "gp3");
    }
}

How does gp3 differ from gp2?

With gp2, performance is tied to volume size: you get three IOPS per gigabyte, with a minimum burst of 3000 IOPS for small volumes via a burst credit mechanism. A 100 GiB gp2 volume delivers only 300 baseline IOPS, so you must over-provision size just to get speed. With gp3, you get a flat baseline of 3000 IOPS and 125 MB/s of throughput regardless of size, and you can independently provision up to 16000 IOPS and 1000 MB/s. On top of this, gp3 is roughly twenty percent cheaper per GiB.

| Feature | gp2 | gp3 |
|---|---|---|
| Baseline IOPS | 3 per GiB (min 100) | 3000 flat |
| Max IOPS | 16000 (at 5334+ GiB) | 16000 (independently) |
| Baseline throughput | Tied to IOPS | 125 MB/s flat |
| Max throughput | 250 MB/s | 1000 MB/s |
| Cost per GiB | Higher | ~20% cheaper |

// Illustrating the gp2 vs gp3 difference as a simple calculation
package com.bank.infrastructure;

public class VolumePerformanceComparison {
    public static void main(String[] args) {
        int sizeGiB = 100;

        // gp2: locked to 3 IOPS per GiB
        int gp2Iops = sizeGiB * 3; // 300 IOPS for 100 GiB
        System.out.println("gp2 100 GiB baseline IOPS: " + gp2Iops);

        // gp3: 3000 baseline regardless of size
        int gp3BaselineIops = 3000;
        int gp3ProvisionedIops = 6000; // can raise independently
        System.out.println("gp3 100 GiB baseline IOPS: " + gp3BaselineIops);
        System.out.println("gp3 100 GiB provisioned IOPS: " + gp3ProvisionedIops);
    }
}

gp2 100 GiB baseline IOPS: 300
gp3 100 GiB baseline IOPS: 3000
gp3 100 GiB provisioned IOPS: 6000

What are provisioned-IOPS SSD types (io1 and io2)?

These are for workloads that need the highest and most predictable performance, such as the core banking ledger at National Bank of India. io2 improves on io1 with higher durability (99.999% vs 99.9%) and a better IOPS-to-size ratio (500 IOPS per GiB vs 50). io2 Block Express can reach up to 256000 IOPS and 4000 MB/s. You pay a premium, so these are reserved for cases where consistent sub-millisecond latency is critical.

// When provisioned-IOPS is the right choice
package com.bank.infrastructure;

public class ProvisionedIopsDecision {
    public static String evaluateVolumeType(int requiredIops, boolean needsSubMsLatency) {
        if (requiredIops > 16000 || needsSubMsLatency) {
            return "io2"; // exceeds gp3 ceiling or needs guaranteed low latency
        }
        return "gp3"; // gp3 handles up to 16000 IOPS at lower cost
    }
}

What are HDD volume types (st1 and sc1)?

The HDD types are magnetic and optimized for large, sequential throughput rather than small random reads. st1 (throughput-optimized) delivers up to 500 MB/s for big streaming workloads like log processing, batch data warehousing, or Kafka brokers. sc1 (cold HDD) is the cheapest option for data you rarely access. Neither can be used as a boot volume.

// Selecting HDD for sequential workloads
package com.bank.infrastructure;

public class HddVolumeSelector {
    public static String selectHddType(String accessPattern) {
        return switch (accessPattern) {
            case "frequent-sequential" -> "st1"; // log processing, ETL
            case "rare-sequential"     -> "sc1"; // cold audit archive
            default -> throw new IllegalArgumentException("HDD not suitable for: " + accessPattern);
        };
    }
}

How do you migrate from gp2 to gp3?

Migration is done live with the Elastic Volumes feature. You modify the volume type through the console, CLI, or API, and the change happens in the background with no downtime and no detach required. The volume enters an "optimizing" state during the transition. At National Bank of India, the reporting service ran a 100 GiB gp2 data volume that gave only 300 IOPS, and the team considered inflating it to a terabyte just to get speed. Instead, migrating to gp3 gave a 3000 IOPS baseline on the same 100 GiB and allowed provisioning up to 6000 IOPS without buying unused space.

# Live migration from gp2 to gp3 with no downtime
aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3 --iops 6000 --throughput 250

What are the rules and constraints?

EBS volumes are tied to a single Availability Zone and cannot be attached across zones. To move a volume to another zone, you create a snapshot and restore it in the target zone. A volume can be attached to only one instance at a time (except io1/io2 with Multi-Attach). Snapshots are incremental and stored in S3. gp3 IOPS can be provisioned only up to a ratio of 500 IOPS per GiB of volume size.

// Validating IOPS provisioning constraint
package com.bank.infrastructure;

public class IopsValidator {
    private static final int MAX_IOPS_PER_GIB = 500;
    private static final int GP3_MAX_IOPS = 16000;

    public static int validateIops(int sizeGiB, int requestedIops) {
        int maxAllowed = Math.min(sizeGiB * MAX_IOPS_PER_GIB, GP3_MAX_IOPS);
        if (requestedIops > maxAllowed) {
            throw new IllegalArgumentException(
                "Requested " + requestedIops + " IOPS exceeds max " + maxAllowed
                + " for " + sizeGiB + " GiB volume");
        }
        return requestedIops;
    }
}

What about performance tuning and monitoring?

Use CloudWatch metrics to monitor EBS performance: VolumeReadOps, VolumeWriteOps, VolumeQueueLength, and BurstBalance (for gp2). A high queue length indicates the volume is a bottleneck. For gp2, watch BurstBalance dropping to zero, which means the volume has exhausted its burst credits and is throttled to baseline. This is one of the strongest reasons to switch to gp3, where there is no burst credit mechanism and the baseline is always 3000 IOPS.

// Monitoring EBS performance with CloudWatch
package com.bank.monitoring;

import software.amazon.awssdk.services.cloudwatch.CloudWatchClient;
import software.amazon.awssdk.services.cloudwatch.model.*;
import java.time.Instant;
import java.util.List;

public class EbsMonitor {
    private final CloudWatchClient cw = CloudWatchClient.create();

    public double getAverageQueueLength(String volumeId) {
        GetMetricStatisticsResponse resp = cw.getMetricStatistics(
            GetMetricStatisticsRequest.builder()
                .namespace("AWS/EBS")
                .metricName("VolumeQueueLength")
                .dimensions(Dimension.builder().name("VolumeId").value(volumeId).build())
                .startTime(Instant.now().minusSeconds(3600))
                .endTime(Instant.now())
                .period(300)
                .statistics(Statistic.AVERAGE)
                .build());
        return resp.datapoints().stream()
            .mapToDouble(Datapoint::average).average().orElse(0.0);
    }
}

When should you use each volume type?

• gp3 – the default for most workloads: boot volumes, application data, medium databases, development environments.
• io2 – core banking databases, Oracle RAC, any workload needing more than 16000 IOPS or guaranteed sub-millisecond latency.
• st1 – Kafka brokers, Hadoop HDFS, log aggregation, ETL data staging.
• sc1 – cold compliance archives, infrequently accessed backups.
• gp2 – legacy only; migrate to gp3 for better performance at lower cost.

// Decision matrix for volume type selection
package com.bank.infrastructure;

public class VolumeTypeAdvisor {
    public static String advise(int requiredIops, boolean sequential, boolean cold) {
        if (cold) return "sc1";
        if (sequential) return "st1";
        if (requiredIops > 16000) return "io2";
        return "gp3";
    }
}