How Do AWS EC2 Standard C-Series and NVMe Instances Differ?

Amazon EC2 compute-optimized C-series instances come in two primary storage configurations, consisting of standard EBS-only instances and instances equipped with local NVMe SSD instance store volumes. While both variants deliver identical vCPU and memory ratios designed for compute-intensive workloads, they differ fundamentally in storage architecture, data persistence, input/output latency, and hourly pricing. Standard instances rely entirely on network-attached Amazon Elastic Block Store for storage, whereas NVMe-equipped instances, denoted with a d suffix in their instance type name, include physically attached solid-state drives on the host server. Choosing between them depends on whether an application requires persistent block storage or ultra-fast, temporary scratch space.

Naming Conventions in the C-Series Family

Amazon Web Services uses a structured naming convention to distinguish between standard compute-optimized instances and those with local NVMe storage. In any generation and processor architecture, a standard instance name consists of the family letter, generation number, optional processor identifier, and size. When local NVMe storage is included, the letter d is appended before the dot and size designation.

• Intel-based instances: c5.large vs. c5d.large, c6i.xlarge vs. c6id.xlarge, c7i.2xlarge vs. c7id.2xlarge
• AMD-based instances: c5a.large vs. c5ad.large, c6a.xlarge vs. c6ad.xlarge
• AWS Graviton-based instances: c6g.large vs. c6gd.large, c7g.xlarge vs. c7gd.xlarge

Storage Architecture and Performance

The core difference between these two instance variants lies in how storage is connected to the underlying hypervisor and virtual machine.

Standard C-Series Instances (EBS-Only)

Standard C-series instances (c6i, c7g, c6a, etc.) are EBS-only. They do not have any physical disks exclusively allocated to them on the local host hardware. Instead, all storage volumes—including the root volume and any attached data volumes—are provisioned over the network using Amazon Elastic Block Store (EBS).

Although these instances use dedicated EBS bandwidth (often enhanced via the AWS Nitro System) to prevent storage traffic from competing with general network traffic, every read and write operation still traverses the internal AWS network fabric. Consequently, latency typically starts around a fraction of a millisecond to a few milliseconds depending on the EBS volume type (gp3, io2 Block Express), and IOPS and throughput are governed by both the instance's maximum EBS bandwidth limits and the provisioned limits of the attached EBS volumes.

C-Series Instances with Local NVMe Storage

C-series instances with the d suffix (c6id, c7gd, c5ad, etc.) still support EBS volumes for persistent storage and root devices, but they also include one or more Non-Volatile Memory Express (NVMe) SSDs physically attached to the host server's PCIe bus.

Because the NVMe drives reside directly on the physical host, I/O operations bypass the network stack completely. This provides:

• Sub-millisecond latency: Significantly lower and more consistent read/write latency compared to network-attached block storage.
• High random IOPS: Capable of delivering hundreds of thousands of IOPS directly out of the box without provisioning extra storage capacity or paying per-IOPS fees.
• Proportional scaling: The capacity and number of local NVMe drives scale linearly with the instance size. If a single unit of instance size provides a specific capacity \(C_{\text{base}}\) and throughput \(T_{\text{base}}\), scaling up by a multiplier \(k\) generally yields a total local storage capacity of \(C_{\text{total}} = k \cdot C_{\text{base}}\).

Data Persistence and Lifecycle

Understanding the lifecycle of data on local NVMe storage versus EBS is critical for preventing accidental data loss.

Ephemeral Nature of Local NVMe Instance Store

The local NVMe storage attached to d variant instances is an EC2 Instance Store, which provides temporary (ephemeral) block-level storage. Data written to local NVMe drives persists only during the lifecycle of the running instance under specific conditions:

• Instance Reboot: Data survives if the guest operating system reboots (sudo reboot or via the RebootInstance API).
• Instance Stop or Hibernate: Data is permanently lost when the instance is stopped (StopInstances API), because starting the instance again usually migrates it to a new physical host.
• Instance Termination: Data is permanently lost upon termination.
• Hardware Failure: Data is lost if the underlying physical drive or host server fails.

Persistent Nature of EBS on Standard Instances

Because standard C-series instances store all data on Amazon EBS, the storage lifecycle is decoupled from the compute instance lifecycle:

• Stop and Start: Stopping a standard C-series instance preserves all data on the attached EBS volumes.
• Snapshots and Backups: EBS volumes support native point-in-time snapshots to Amazon S3, automated lifecycle policies, and detached volume reattachment to other instances.
• Built-in Redundancy: EBS volumes automatically replicate data within their Availability Zone to protect against single-drive hardware failures.

Security and Encryption

Both standard and NVMe-equipped C-series instances built on the AWS Nitro System incorporate hardware-level security, though key management differs:

• Local NVMe Encryption: On Nitro-based d instances, all local NVMe instance store volumes are automatically encrypted using an XTS-AES-256 block cipher implemented in a dedicated hardware module on the Nitro card. The encryption keys are generated randomly per drive when the instance boots and are destroyed permanently when the instance stops or terminates. You cannot manage, export, or rotate these keys via AWS KMS.
• EBS Encryption: On both standard and d instances, EBS volumes can be encrypted using AWS Key Management Service (KMS) keys, allowing full control over customer-managed keys (CMKs), key rotation, and IAM access policies.

Pricing and Total Cost of Ownership

On an hourly compute basis, C-series instances with local NVMe storage carry a higher on-demand, Reserved Instance, and Spot price than their standard counterparts of the same size. For a running duration \(t\), the total cost \(Cost_{\text{standard}}\) of a standard instance compared to \(Cost_{\text{nvme}}\) can be modeled as:

\[Cost_{\text{standard}}(t) = R_{\text{compute}} \cdot t + C_{\text{EBS\_GB}} \cdot S_{\text{GB}} \cdot t + C_{\text{IOPS}} \cdot I_{\text{prov}} \cdot t\]

\[Cost_{\text{nvme}}(t) = R_{\text{compute\_d}} \cdot t + C_{\text{EBS\_root}} \cdot S_{\text{root}} \cdot t\]

Where:

• \(R_{\text{compute}}\) and \(R_{\text{compute\_d}}\) are the hourly compute rates (\(R_{\text{compute\_d}} > R_{\text{compute}}\)).
• \(C_{\text{EBS\_GB}}\) and \(C_{\text{IOPS}}\) represent the extra costs of provisioning high-capacity, high-IOPS EBS volumes (io2 or high-performance gp3).

If a workload requires high temporary IOPS and throughput, a d instance is often more cost-effective than a standard C-series instance paired with expensive provisioned-IOPS EBS volumes, because the local NVMe IOPS and storage capacity are bundled directly into the hourly instance price.

Feature Comparison Summary

Ideal Use Cases for Each Variant

When to Choose Standard C-Series Instances

• Stateless microservices and web servers: Workloads where compute is the bottleneck and local disk I/O is minimal.
• Containerized workloads with remote state: Kubernetes (EKS) or ECS nodes where state is stored in managed databases (RDS, DynamoDB) or shared filesystems (EFS).
• Instances that stop and start frequently: Development environments or batch servers that are stopped outside of business hours to save compute costs while preserving disk state.

When to Choose C-Series Instances with Local NVMe Storage

• High-performance scratch space and video encoding: Media transcoding, scientific modeling, and EDA workloads that generate large intermediate files requiring rapid read/write cycles before uploading final outputs to Amazon S3.
• Distributed caches and replicated NoSQL databases: Self-managed clusters (such as Redis, Aerospike, or Apache Cassandra) that handle data replication at the application layer across multiple Availability Zones and benefit from ultra-low disk latency.
• Big data shuffle and spill operations: Apache Spark, Hadoop, or Presto nodes that frequently spill large intermediate query datasets to disk during complex joins and aggregations.
• CI/CD build agents: Ephemeral build runners that check out large repositories, compile artifacts with heavy disk I/O, push images to a registry, and terminate immediately afterward.