Amazon EC2 C9g and C9gd Instances with AWS Graviton5: Now Generally Available

Amazon EC2 C9g and C9gd instances, powered by AWS Graviton5 processors, are now generally available. These compute-optimized instances target workloads such as real-time analytics, batch processing, video encoding, scientific modeling, and CPU-based machine learning inference. Compared to previous-generation C8g instances, C9g delivers up to 25% higher performance per vCPU. They also feature DDR5 8800MT/s DIMMs, the fastest memory of any processor instance in the cloud; 5x more L3 cache; and up to 3x higher packet-processing performance than Graviton4-based instances.

Faster memory and larger caches reduce the time CPUs wait on data. This directly improves throughput for in-memory analytics, shortens agentic loop iterations, and makes real-time applications more responsive. Higher packet-processing performance benefits network-intensive services such as ad serving, load balancers, and network functions that rely on per-packet CPU work.

Key specifications:

• 11 sizes: medium through 48xlarge, plus a bare metal option.
• Up to 192 vCPUs, 384 GiB memory, 100 Gbps network bandwidth, and 72 Gbps EBS bandwidth (2x increase over previous generation).
• On average, up to 15% higher network bandwidth and 20% higher EBS bandwidth across sizes.
• Instance Bandwidth Configuration (IBC) allows adjusting allocation between EBS and VPC networking by up to 25%.
• Support for ENA Express, up to 128 EBS volumes, Savings Plans, On-Demand, Spot, Dedicated Instances, and Dedicated Hosts.

C9gd adds local NVMe SSD storage with up to 30% higher storage performance than previous-generation local storage instances. Use C9gd for HPC simulation scratch space, temporary ML inference caches, or local buffers for ad-serving engines. C9gd instances also expose detailed I/O performance statistics via Amazon CloudWatch or nvme-cli, including latency histograms by I/O size at 1-second granularity.

For distributed analytics, batch jobs, or video encoding pipelines that can rely on EBS, choose C9g. For sub-millisecond local access or ephemeral data, C9gd is the appropriate variant. Both families feature the Nitro Isolation Engine, which enforces VM isolation through a minimal API set and uses formal verification to provide mathematically precise isolation guarantees.

C9g instances are the first compute-optimized family built on AWS Graviton5 processors, with a memory subsystem centered on DDR5 8800MT/s DIMMs, the highest memory data-transfer rate available in cloud instances. The 8800MT/s figure describes the sustained transfer rate across the DRAM bus; it raises the memory bandwidth ceiling relative to the previous generation. The processor also integrates 5x more L3 cache. Because L3 is shared on-die, a larger cache lets a greater fraction of the working set be serviced at cache latency instead of DRAM latency. This matters because a DRAM access costs hundreds of cycles, while an L3 hit avoids that stall entirely on the critical path.

For memory-bound code, the practical effect is less time spent waiting on data. In-memory analytics workloads that scan or hash-join large tables see fewer stalls at the memory controller. Agentic AI loops, which interleave short CPU-bound reasoning steps with frequent state reads, benefit from hot state remaining resident in cache. Real-time applications, such as stream processors and scoring engines, reduce tail latency because per-request memory stalls shrink.

The network and storage paths also improved. Across C9g sizes, network bandwidth is up to 15% higher and EBS bandwidth up to 20% higher on average compared with the previous generation. The 48xlarge size delivers up to 100 Gbps of network bandwidth and up to 72 Gbps of EBS bandwidth, a 2x increase. Graviton5 also provides up to 3x higher packet-processing performance, which is relevant for workloads that saturate packet rate before bandwidth.

• DDR5 8800MT/s DIMMs raise the memory-bandwidth ceiling; 5x larger L3 cache reduces DRAM round trips.
• Up to 3x higher packet-processing performance benefits packet-rate-bound workloads such as load balancers and network appliances.
• Up to 15% higher network bandwidth and 20% higher EBS bandwidth on average across sizes.
• The 48xlarge size offers up to 100 Gbps network and up to 72 Gbps EBS bandwidth, a 2x increase over the prior generation.
• Instance Bandwidth Configuration (IBC) can reallocate up to 25% of bandwidth allocation between EBS and VPC networking; ENA Express is supported for enhanced networking.

When selecting instances, profile the workload memory access pattern. If the hot working set fits in the larger L3, expect higher effective throughput. For large streaming reads that miss cache, the DDR5 bandwidth dominates. Use IBC to shift bandwidth toward EBS for database-style workloads or toward VPC for network-heavy services, and choose C9gd variants when local NVMe scratch storage is required.

C9g and C9gd instances are compute-optimized families powered by the same processor, but they differ fundamentally in storage architecture. C9g instances are designed for workloads that use Amazon Elastic Block Store (Amazon EBS) as the primary storage layer. Because EBS volumes are network-attached, they provide durable, persistent storage that is independent of the instance lifecycle. This makes C9g a solid fit for batch jobs, video encoding pipelines, distributed analytics, and CPU-based machine learning inference where the dataset or model artifacts must survive instance stops or terminations.

C9gd instances include local NVMe SSD storage that is physically attached to the host server. This direct-attached storage offers substantially higher throughput and lower latency than EBS, because data does not traverse the network. However, the instance store is ephemeral: any data written to it is lost when the instance is stopped, terminated, or experiences a hardware failure. Therefore, choose C9gd only for workloads that tolerate ephemeral data or can reload it from a durable source.

Concrete use cases for C9gd include:

• Scratch space during HPC simulations — intermediate results that are regenerated on rerun and can be written to fast local disk.
• Temporary caches for ML inference — feature caches or preprocessed inputs that can be rebuilt from an EBS-backed source.
• Local buffers for ad-serving engines — frequently updated impression or click data used for real-time decisions, where persistence is not required.

C9gd instances offer up to 30% higher storage performance compared to previous-generation local storage instances. For monitoring, the NVMe instance store supports detailed performance statistics, including latency histograms broken down by I/O size, with up to 1-second granularity. You can access these metrics through Amazon CloudWatch or via nvme-cli at no additional cost. This granular visibility helps engineers identify whether latency issues are caused by read/write mix, queue depth, or specific I/O sizes, rather than relying on aggregate averages.

Selection guidance:

• Use C9g when data durability and persistence on EBS are mandatory, or when the workload primarily needs compute capacity with standard block storage.
• Use C9gd when low latency and high local I/O throughput outweigh the need for persistence, and when the application can regenerate or rehydrate temporary data.

Both families share compute characteristics, but the storage choice determines the performance and durability profile. For durable state, stay with C9g. For high-speed temporary data, C9gd is the appropriate option.

Content generation failed for this section.

The AWS Nitro System provides the underlying foundation for Amazon EC2 instance security. Within this architecture, the Nitro Hypervisor is responsible for isolating virtual machines from one another and from AWS operators, using dedicated hardware and firmware to minimize the attack surface. The Nitro Isolation Engine builds directly on this design as an enhancement to the Nitro System, with a focused responsibility: enforcing isolation between virtual machines. It is a purpose-built component that mediates all access to virtual machine memory, CPU register state, and I/O devices through a minimal set of APIs. By reducing interactions to a small, well-defined interface, the engine limits the pathways an attacker could attempt to exploit, a principle aligned with reducing trusted computing base.

The key distinction of the Nitro Isolation Engine is its use of formal verification. Rather than relying solely on manual review, penetration testing, or best-practice hardening, the engine’s isolation properties are mathematically proven. Formal verification models the system’s behavior and exhaustively checks that the implementation enforces the specified isolation guarantees under all possible inputs and states. This provides a level of assurance that goes beyond conventional testing: it offers mathematically precise evidence that virtual machine isolation cannot be bypassed through API misuse, malformed requests, or edge cases in hardware mediation. The scope and assumptions of these formal proofs are documented in a technical white paper, allowing security engineers to evaluate exactly what is guaranteed and under which conditions.

The Nitro Isolation Engine enforces isolation across the critical resources that define a virtual machine:

• Memory: all DMA and memory access is mediated to prevent cross-VM reads or writes.
• CPU register state: context isolation prevents leakage of register contents between instances.
• I/O devices: every device access is mediated through the minimal API surface, preventing direct hardware manipulation.

C9g and C9gd instances are the first compute-optimized instance types to feature the Nitro Isolation Engine. These instances, powered by AWS Graviton5 processors, therefore provide an additional security boundary for compute-intensive workloads such as batch processing, video encoding, scientific modeling, and CPU-based machine learning inference. For enterprise teams deploying multi-tenant architectures or handling sensitive data, the Nitro Isolation Engine raises the security bar by making isolation guarantees explicit, minimal, and formally verified, complementing the existing protections of the Nitro Hypervisor with a mathematically grounded defense.

C9g and C9gd instances, powered by AWS Graviton5 processors, are now generally available in the following AWS Regions, with additional Regions to follow:

• US East (Ohio)
• US East (N. Virginia)
• US West (Oregon)
• Europe (Frankfurt)

Both families are offered in 11 sizes ranging from medium to 48xlarge, plus a bare-metal option. The largest virtual and bare-metal sizes provide up to 100 Gbps network bandwidth and up to 72 Gbps EBS bandwidth. C9gd sizes add local NVMe SSD instance storage for workloads that require low-latency, high-throughput scratch space or temporary caches.

Instances can be launched today using the AWS Management Console, the AWS Command Line Interface (AWS CLI), or AWS SDKs. In the console, navigate to the EC2 service, choose Launch Instance, and filter the instance family by C9g or C9gd before selecting a size and an Amazon Machine Image (AMI) compatible with the Graviton5 architecture.

For programmatic provisioning, the standard run-instances workflow applies. The following example launches a c9g.medium instance in the US East (N. Virginia) Region:

aws ec2 run-instances \
  --instance-type c9g.medium \
  --image-id <ami-id> \
  --region us-east-1

Replace <ami-id> with a valid Graviton5-compatible AMI, retrievable via the describe-images command or the EC2 console. AWS SDK users can replicate this request in their preferred language using the equivalent EC2 RunInstances API call.

For cost details, refer to the Amazon EC2 Pricing page. C9g and C9gd support On-Demand, Spot Instances, Savings Plans, Dedicated Instances, and Dedicated Hosts, with hourly pricing varying by Region and instance size.

For full specifications, including Instance Bandwidth Configuration (IBC), ENA Express support, and EBS volume limits, see the EC2 C9g/C9gd instances page. Feedback can be submitted through AWS re:Post for EC2 or through your usual AWS Support contacts.