When the working set stops fitting
Every tuning trick in the manual stops helping the moment your data no longer fits in memory. This line exists so it keeps fitting: registered ECC DDR5, real server topology, and enough cores to do something with it.
When the working set stops fitting in RAM, nothing else you tune matters. This line exists so that it keeps fitting: ECC memory, real server topology, and enough cores to use it.
| Plan | Dedicated cores | Memory | NVMe storage | Port speed | Price | |
|---|---|---|---|---|---|---|
| E-8 Entry into ECC | 8 | 64 GB | 500 GB | 25 Gbit/s | €89.00 /mo | Configure |
| E-16Most taken The workhorse tier | 16 | 128 GB | 1 TB | 25 Gbit/s | €165.00 /mo | Configure |
| E-32 A full socket | 32 | 256 GB | 2 TB | 25 Gbit/s | €310.00 /mo | Configure |
| E-48 Half a terabyte of RAM | 48 | 512 GB | 4 TB | 25 Gbit/s | €580.00 /mo | Configure |
Prices exclude VAT where applicable. Traffic: Unmetered, fair use.
AMD EPYC 9354P · Zen 4 · 32C/64T · ECC DDR5-4800 · NUMA-aware pinning
Thirty-four cities, twenty-nine countries
Latency figures are measured medians from our own probes, not vendor brochures. They move; the page updates when they do.
What server silicon is for
A desktop part with a big cooler is not a server. The difference is not the badge; it is memory capacity, memory correction, PCIe lanes and the ability to keep every core fed at once.
EPYC 9354P, thirty-two cores, twelve memory channels, one socket.
The 9354P gives us thirty-two Zen 4 cores and sixty-four threads on a single socket, wired to twelve channels of registered DDR5-4800. Twelve channels is the whole point. On a two-channel desktop platform, sixteen busy cores spend a meaningful share of their day waiting on memory rather than computing; here they do not.
Single-socket is also deliberate. There is no second processor to hop to, no inter-socket link to saturate, and no chance of a scheduler placing your threads on one side of the machine and your memory on the other. Fewer things to get wrong means fewer support tickets that begin with the words “it was fine yesterday”.
Half a terabyte in one instance
The top tier carries five hundred and twelve gigabytes of correcting memory. Analytical databases, in-memory caches, JVM heaps that nobody has been brave enough to profile — all of it fits without a sharding project.
Cores that stay busy together
Forty-eight threads all doing real work is a different problem from one thread going quickly. Bandwidth per core is what makes the second case possible, and it is the figure desktop platforms cannot match at any clock speed.
PCIe lanes to spare
Enough lanes that NVMe, network and passthrough devices are not competing for the same narrow path. This is the same host platform underneath the GPU and storage lines, for exactly that reason.
Predictable, rather than peaky
Clock speeds here are lower than on the Ryzen line and far flatter. For anything with a latency budget measured at the ninety-ninth percentile, flat is worth more than fast.
ECC, and what it actually does
Memory errors are not exotic. On a large fleet they happen weekly, and on a machine without correction they happen invisibly, which is the part that should worry you.
Correction is not a checkbox. It is a log you can read.
Registered ECC DDR5-4800 corrects single-bit errors in flight and detects multi-bit ones. A corrected error becomes a line in a log rather than a wrong number in your result set. When a module starts producing them at a rate we do not like, it gets replaced during a scheduled window, before it becomes an uncorrectable error and an unplanned reboot.
The practical case for this is not reliability theory. It is that a database with one flipped bit in a page cache does not crash: it writes the flipped value to disk, replicates it faithfully to every standby, and lets you discover the problem in six weeks when a report disagrees with itself.
Correction counters for your own instance are visible in the panel. If you would rather watch them yourself, the same figures are exposed through the API.
Who should not buy this
Server silicon is not automatically the better choice. It is the better choice for a specific and fairly narrow set of problems.
Half the people who ask for EPYC want the Ryzen line and a good night’s sleep.
Your bottleneck is one thread
A 9354P core is slower than a 9950X core, and no amount of memory bandwidth changes that. If your profiler shows one thread at a hundred percent and thirty-one cores asleep, you are shopping in the wrong line.
You are buying it for the badge
Nothing about a workload becomes enterprise-grade because it runs on a part with EPYC written on it. Buy this when the memory figure or the core count is genuinely the constraint, and buy the cheaper line when it is not.
You need forty terabytes
The NVMe here tops out in the low single-digit terabytes. Bulk capacity lives in the storage line, on the same host platform, at a fraction of the cost per terabyte.
You want a GPU in it later
Cards are not added to running EPYC instances. The GPU line exists because passthrough requires the host to be laid out for it from the start.
You want the whole machine
From the E-32 tier upward you are holding a full socket, but the hypervisor is still ours. If your requirement is your own kernel, your own scheduler or nested virtualisation at full speed, buy metal instead.
Allocation, and where NUMA comes in
Buying memory is easy. Making sure the cores that use it are physically near it is the part that distinguishes a server platform from a spreadsheet of specifications.
Pinned cores, reserved memory, and both on the same side of the machine.
Cores are pinned to physical cores, one tenant per core and its sibling thread, exactly as on the Ryzen line. What changes here is placement: your memory is allocated from the NUMA domain your cores sit in, so a memory access does not cross the fabric to reach the address it wants. Instances too large for one domain are pinned across the smallest number of domains that will hold them, and the topology is passed through, so your own scheduler can see the truth.
Two cores of the thirty-two are reserved for the hypervisor, storage and monitoring. The rest are sold once. When they are gone the site stops appearing in the configurator for this line, which is occasionally annoying and always honest.
| Resource | How it is allocated | What is shared |
|---|---|---|
| CPU cores | Pinned within a NUMA domain wherever the size allows | Nothing |
| Memory | Reserved at boot from the local domain. Registered ECC | Nothing |
| Topology | Passed through, so your guest scheduler sees real distances | Not applicable |
| NVMe capacity | Thick-provisioned at creation | Nothing |
| Network port | Twenty-five gigabits per second, dedicated | Site uplink, engineered above the sum |
| Hypervisor overhead | Two reserved cores per node, outside your allocation | Not applicable |
Disks and the wire
The reference node carries four enterprise NVMe drives in mirrored pairs with a hot spare, and two twenty-five gigabit interfaces bonded to separate switches.
Four Gen4 NVMe per node, mirrored, on a twenty-five gigabit port.
Mirrored, with power-loss protection
Writes acknowledge from capacitor-backed cache. A power event flushes that cache rather than discarding it, which is the difference between a clean journal replay and a long evening.
Bonded uplinks, separate switches
Two interfaces in a link aggregation group landing on distinct switches. A switch reboot costs you a few dropped packets rather than an outage.
Filtering that is already on
Up to twelve terabits per second of scrubbing at the edge, permanently in path. Nothing to enable when an attack starts, because it is already filtering when it does.
Unmetered, with a published number
Fair use on a twenty-five gigabit port is a hundred and fifty terabytes a month. The figure is written on the pricing page rather than left vague so it can be used against you later.
Bring your own addresses
From the E-32 tier upward, at sites where the upstream permits it, you can announce your own IP space. Open a ticket with the object details and we will answer within a day.
Forty gigabits, if you need it
A dedicated forty-gigabit port is available on this line wherever the site has the capacity behind it. It is a paid option, priced on the pricing page, and most people do not need it.
Where it runs, and moving in
Seven sites do not: Reykjavík, Sofia, Chișinău, Panama City, Santiago, Mumbai and Johannesburg. Those are Ryzen and storage sites, and the configurator will tell you so before you get attached to the idea.
Twenty-seven of the thirty-four sites carry EPYC capacity.
Everything else has it, including all five North American sites and every Asian site except Mumbai. Frankfurt and Amsterdam hold the most capacity and get new hardware first. Zurich carries EPYC but rations it, because the rack space there costs what Zurich rack space costs.
- 01
Size by memory, not by cores
Work out the resident set at peak, add whatever your page cache genuinely earns, and buy the tier above that. Core count on this line tends to arrive as a consequence of the memory figure rather than as a separate decision.
- 02
Test on a monthly term
Take one instance for a month before committing to two years at the discounted rate. The seven-day refund covers the first week if the answer turns out to be no.
- 03
Move the data over the wire
Twenty-five gigabits and unmetered traffic makes a multi-terabyte copy an overnight job. For anything larger, ask support about a seeded transfer rather than inventing a courier plan.
- 04
Keep the topology in mind
If your application pins its own threads, read the topology we expose rather than assuming a flat machine. Getting this wrong is the single most common cause of a migration looking slower than the hardware it replaced.
- 05
Grow in place where possible
Memory and NVMe expand on the same node when it has room. A jump that the node cannot absorb becomes a live migration, scheduled with you, usually inside a working day.
When a node fails
Large instances take longer to come back, because half a terabyte of memory has to be populated from somewhere. We would rather say that than imply otherwise.
The same failure path as the rest of the fleet, with more memory to refill.
Drive failures are absorbed by the mirror and the hot spare, with no interruption to your instance. A memory module going bad is usually caught by rising correction counts before it becomes uncorrectable, and it gets replaced in a window agreed with you. Both of those are routine, and neither of them is an incident.
A node lost outright is rebuilt onto standby hardware in the same site, with your addresses following. Restart on a small instance takes minutes. On the largest tier the honest figure is closer to half an hour, most of it spent moving data rather than deciding what to do.
Correction counts are yours to read
You do not have to take our word for the health of the memory under your instance. The counters are in the panel and in the API.
Credits are automatic
Contractual uptime is 99.99% a month. Missing it puts a credit on your account without a claim form, a phone call or an argument about causation.
Replication beats hope
A single instance is a single instance, whatever the hardware costs. If the workload cannot lose thirty minutes, run a standby in a second site and practise the failover before you need it.
Questions about this line
Because it is what we can buy, rack and cool in volume today at a price that keeps this line where it is. The 9354P is a mature part with known thermal behaviour and no firmware surprises. When a newer server generation makes sense for the fleet, it will appear in the changelog rather than quietly under existing instances.
Twelve registered DDR5-4800 modules per node, correction on, counters exposed. Read them in your panel or through the API. Anyone claiming ECC without showing you the counters is asking you to trust a specification sheet.
From the E-32 tier upward, yes, and it is a supported image. Nested virtualisation works but carries a real performance cost. If the nested guests are the actual product, bare metal is the honest answer.
If the database fits in memory on Ryzen and your queries are mostly single-threaded, Ryzen wins on latency and costs less. Once the working set exceeds a hundred and twenty-eight gigabytes, or once you have many concurrent expensive queries, EPYC wins by a margin that grows with the size of the problem.
Your cores and your memory are placed in the same domain, so an access does not cross the fabric. Instances too large for one domain span the fewest that will fit, and we pass the real topology through so your own scheduler is not guessing.
From the E-32 tier upward, at sites where the upstream allows it. Send the object details in a ticket and you will have an answer within a day, including a plain no if the site cannot do it.
Buy the memory figure you actually need
Pick a tier by resident set rather than by core count, take it for a month, and move up in place if the number was wrong. Payment is in coin, sign-up is an email address, and the first week is refundable without a reason.