The C8gn Graviton4 instances at 600 Gbps reach Paris and now span 30 AWS regions
On August 28 2026 AWS made EC2 C8gn instances, powered by Graviton4 and capable of 600 Gbps of network bandwidth, available in the Europe (Paris) region. For teams running virtual network appliances or high-throughput analytics, this European expansion reshapes the cost-performance case for arm64.
August 28 2026. AWS announces availability of EC2 C8gn instances in the Europe (Paris) region. 600 Gbps. That is the peak network bandwidth of these instances, the highest across EC2’s network-optimized line. 30 regions. That is now the footprint of this Graviton4 family. In one announcement, AWS’s top network tier moves to arm64 and becomes available to European high-throughput workloads.
What C8gn is, in numbers
The C8gn family is the network-optimized variant of the Graviton4 generation. Three figures define it. Up to 30 % more compute performance than the C7gn instances built on Graviton3. 600 Gbps of network bandwidth, the most among network-optimized instances. And 6th-generation Nitro cards, the offload substrate that moves networking and storage functions to dedicated hardware.
The lineup scales up to 48xlarge, with up to 384 GiB of memory and up to 120 Gbps of EBS bandwidth. On the 16xlarge, 24xlarge, 48xlarge and metal sizes, the instances support Elastic Fabric Adapter (EFA), the low-latency fabric built for HPC clusters and tightly coupled workloads.
The sixth-generation Nitro cards deserve a word of their own. They offload packet processing, encryption and EBS I/O from the host CPU, which is exactly why the network-optimized tier can advertise both 600 Gbps and strong per-core performance at once. On a virtual appliance that inspects every packet, that offload is the difference between throughput that survives the firewall and throughput that collapses under it.
AWS’s intent is explicit: position C8gn for virtual network appliances, data analytics and CPU-based AI/ML inference. Three workload families where network throughput, more than raw compute, is the bottleneck.
Why 600 Gbps changes the calculus
The “n” in C8gn marks the network-optimized line. Historically this segment was dominated by x86 instances: virtual firewalls, security appliances, packet sniffers, load balancers and gateways. These workloads move massive volumes of packets and rarely care about the core architecture — they want deterministic throughput.
Putting 600 Gbps on Graviton4 means offering that throughput at the arm64 price, structurally cheaper than the x86 equivalent. The cost-performance equation shifts: the dominant cost driver of network-optimized workloads — bandwidth and Nitro cards — stays the same, but the core beside it costs less.
The 30 % figure over C7gn matters too. It means the generation-over-generation move does not come at a regression cost: you gain compute at the same time as throughput, without leaving the instance family.
A network-optimized lineage with a track record
The “n” suffix is not new. AWS built the network-optimized Graviton line by iteration: C6gn on Graviton2, C7gn on Graviton3, and now C8gn on Graviton4. Each generation jumped bandwidth while improving the throughput-per-euro ratio in favor of arm64.
That trajectory matters because it lowers the perceived risk of switching. A network-optimized workload moving from C7gn to C8gn does not change paradigm: it stays on arm64, keeps its images, and gains 30 % of compute plus higher throughput. The break exists only for those coming from the x86 world, and that is where the preparation work concentrates.
Nor is the Graviton4 family limited to networking. It spans C8g for general purpose, C8gd for local NVMe storage, and R8g for memory. Having the top network tier join that family completes the arm64 portfolio and simplifies the decision for an organization that wants to standardize its fleet on a single architecture.
The real prerequisite: arm64, everywhere
Moving to C8gn is not a simple instance-size change. It is an architecture change. Every image — OS, dependencies, binaries — must exist for arm64, and the ecosystem is still uneven.
Base images from the major systems are broadly multi-arch. Compiled applications, however, can still depend on x86 binaries that were never ported. A proprietary network appliance shipped only as x86_64 will not run on C8gn without emulation, and emulation destroys exactly the throughput benefit you were chasing.
The consequence is simple: audit images and binaries before any migration. A modern containerized workload with multi-arch images migrates in hours; a single-architecture legacy appliance can demand a rewrite that AWS’s announcement does not mention.
Paris and Europe: what the expansion changes
The arrival of C8gn in Paris is not cosmetic. It joins Frankfurt, Stockholm, Ireland, London, Spain, Zurich and Milan — eight European regions in total. For a network-optimized workload, regional proximity determines first-byte latency and inter-region transfer cost.
For teams bound by data-residency or latency constraints on the French market, having the top network tier in the Paris region removes the trade-off between compliance and performance. You no longer choose a distant region to reach 600 Gbps; you find it next to your users.
The expansion is part of a broader AWS move: densify every region with the full Graviton4 lineup, including the network, storage and compute-intensive variants. Paris is catching up on a relative gap against the older American regions.
Where C8gn sits relative to GPU
C8gn is not a model-training instance. For that, AWS is pushing the P6-B300, fitted with Blackwell Ultra and 6.4 Tbps of EFA networking, itself expanded to new regions on the same August 28. C8gn targets a different niche: the data plane and CPU inference, where network throughput and core cost matter more than tensor compute.
The two families are not competitors, they are complements. A typical inference architecture routes traffic through C8gn appliances before it reaches GPUs, or serves lightweight models directly on arm64. Understanding that split avoids over-provisioning a GPU for a load that 600 Gbps of Graviton4 already absorbs.
What to verify before migrating
A move to C8gn is prepared in three checks. First, the arm64 inventory: confirm that every image, dependency and embedded binary exists for arm64. Second, EFA eligibility: EFA networking, useful for tightly coupled clusters, is only available on certain sizes — check it matches your needs before sizing. Third, appliance compatibility: a virtual network appliance supplied by a vendor must be explicitly validated for arm64 by that vendor.
The benefit lands on workloads that dominate the network bill. A filtering appliance at several tens of Gbps, a streaming analytics platform or a CPU inference gateway will see core cost fall without touching throughput. Conversely, a workload tied to exclusive x86 software has nothing to gain in the short term.
Finally, benchmark on real sizes. The 600 Gbps ceiling is only reached on the large sizes; a modest appliance sees only a fraction of the cap. Sizing against actual consumed throughput, not the advertised maximum, is what separates a profitable migration from needless overspend — and it is the one step that takes real measurement, not a datasheet.
Verdict
If your network-optimized workloads are containerized or multi-arch, benchmark C8gn against your current x86 instances: at equal throughput the Graviton4 core costs less, and the 30 % gain over C7gn makes the switch nearly free.
If you depend on exclusive x86 appliances or binaries, do not force the migration: first price the port or the emulation, which can erase the saving. 600 Gbps is only an advantage for those who can use it on arm64.