AMD EPYC Was Not a Spec-Sheet Decision
A lot of infrastructure choices look simple from the outside.
You pick a CPU family, put the logo on a landing page, mention performance, and move on.
That is not how we thought about it at Raff.
When we chose AMD EPYC for our cloud infrastructure, we were not trying to collect a nicer hardware badge. We were deciding what kind of platform we wanted to build underneath every VM we offer. That is a much more important decision, because once you commit to a hardware foundation, it shapes everything above it: pricing logic, performance consistency, virtualization behavior, growth planning, and the kind of trust users can place in the platform.
We did not want mixed expectations across the platform
One of the things that bothers me about a lot of cloud infrastructure is inconsistency.
A platform can look simple from the front end while behaving very differently depending on which tier, host, or generation of hardware the customer lands on. That may be normal operationally at scale, but it creates a very uneven experience for the user. A developer should not have to wonder whether performance feels different because the platform made a quiet hardware trade-off in the background.
That is one of the reasons AMD EPYC made sense for us.
We wanted a modern server CPU family that could support the kind of platform consistency we care about. Not just raw compute, but a cleaner baseline across the infrastructure itself.
That matters more than benchmark screenshots.
The CPU choice changes more than compute
A lot of people think CPU selection is mostly about speed.
Of course speed matters. But for a cloud platform, CPU choice affects a much wider set of decisions:
- virtualization efficiency
- memory behavior
- security capabilities
- density and cost planning
- consistency between workloads
- how confidently you can productize your VM tiers
That is why we treated AMD EPYC as an infrastructure decision, not a marketing sentence.
At Raff, we wanted the hardware layer to support a platform that felt modern from the beginning. That means good compute performance, yes, but also a foundation that plays well with virtualization, security-minded workloads, and the kind of cloud structure we are building around VMs, storage, and networking.
We care about practical performance, not only theoretical performance
This is another important distinction.
There is always a temptation in infrastructure marketing to turn hardware into a race of isolated numbers. Core counts, thread counts, lanes, caches, generation names. Those things matter, but most users are not buying a processor in the abstract. They are buying the experience of running a workload.
That means the real question is not:
“How impressive does the processor sound?”
The real question is:
“How does this choice shape the cloud experience on top of it?”
For us, the answer came down to a few practical things:
- stronger modern server performance
- a better foundation for virtualization-heavy environments
- a cleaner long-term price-to-performance story
- a more credible base for workloads that need to feel responsive and predictable
That is why AMD EPYC became part of the platform philosophy, not just part of the hardware inventory.
Virtualization was a major part of the decision
Raff is not selling bare-metal chips to end users.
We are selling a cloud experience built on virtualized infrastructure.
That means the CPU choice has to make sense specifically in a virtualization context.
This is one of the places where AMD EPYC felt right for us. We needed a platform that would support cloud VMs cleanly, not just a chip that looked good in a server rack spec list. The virtualization layer should feel like part of a coherent architecture, not an afterthought on top of generic hardware selection.
That matters because our users are doing real things on these machines:
- deploying web applications
- running development environments
- hosting databases
- building CI or automation flows
- launching containers
- scaling services that should not feel fragile
Those are cloud use cases, not raw CPU lab tests.
And if the hardware foundation is weak or inconsistent, the platform experience inherits that weakness.
Security mattered too
Security was another reason this choice was important.
AMD’s own EPYC platform materials emphasize Infinity Guard and Secure Encrypted Virtualization, which is part of why EPYC has become a meaningful name in cloud and confidential computing conversations. That does not mean every theoretical feature should be overpromised at the product layer, because feature support can depend on generation and provider implementation. But it does mean the CPU family itself aligns with a more security-conscious cloud foundation.
That mattered to us.
Not because we wanted to turn a processor decision into a buzzword-heavy security post, but because infrastructure should be chosen with the next layer in mind. A cloud platform should not be built only for today’s smallest workload. It should be built with enough architectural seriousness that more sensitive or more demanding use cases do not feel like they were bolted onto the wrong hardware later.
We also cared about cost discipline
This part matters just as much as performance.
A lot of infrastructure decisions look strong technically and weak economically. The hardware may be impressive, but if it forces the platform into the wrong pricing logic, the customer ends up paying for the platform’s inefficiency.
We did not want that.
One of the things I care about most is making sure Raff grows in a way that stays understandable for users. That includes hardware choices. If the hardware layer creates the wrong cost structure, then the cloud product above it becomes harder to price cleanly and harder for smaller teams to trust.
AMD EPYC made sense here because we were not only looking for capability. We were looking for a foundation that let us keep building a practical cloud platform around:
That is the more useful frame.
Not “what is the flashiest CPU line?” But “what helps us build the right cloud business and platform on top?”
This is part of why Raff feels like more than a basic VPS product
I think this is where the CPU conversation becomes more interesting.
If a provider is only trying to sell a cheap server as a commodity, then the hardware choice can be treated as a shallow selling point. Just enough to sound modern.
That is not how we think about Raff.
We are building a cloud platform, and that means the infrastructure choices underneath it need to support a broader direction. VMs are the starting point, but not the whole story. Storage matters. Networking matters. Backups matter. Platform direction matters.
That is one reason the AMD EPYC decision fits so well with the rest of the stack. It is part of a wider attempt to make Raff feel modern, consistent, and practical rather than patched together.
The CPU is not the product.
But it absolutely shapes the product.
What this means for users in practice
For users, the benefit is not that they need to memorize EPYC model families.
The benefit is that the platform is built on hardware chosen for the right reasons.
That shows up as a more useful combination of things:
- fast VM provisioning
- a cleaner performance baseline
- infrastructure that feels current rather than legacy
- a foundation that supports virtualization properly
- pricing that is easier to keep rational as the platform grows
This is also one reason our public Linux VM positioning emphasizes the full package rather than the CPU alone. AMD EPYC matters. So does NVMe. So does under-60-second deployment. So does the broader infrastructure story. Those things make more sense together than separately.
That is how we think about cloud architecture internally too.
The bigger lesson is about how platforms should make decisions
If I step back from the CPU topic itself, I think the more important point is this:
a good cloud platform should make infrastructure decisions in the order that strengthens the whole system.
Not the order that creates the best one-line marketing copy.
That means asking questions like:
- Does this hardware help us build a more consistent platform?
- Does it support the virtualization model we care about?
- Does it keep our economics sane?
- Does it align with where the product is going next?
- Does it help us serve real workloads better, not just talk about performance better?
That is the level we tried to think on here.
And that is why I still think this was the right decision.
What This Means for You
If you are evaluating cloud infrastructure, I would not treat CPU branding as a decorative spec.
It is worth asking what the processor choice says about the platform behind it.
Does it look like the provider chose hardware that supports a coherent cloud experience, or just something easy to advertise? Does the rest of the stack make sense around that decision? Will the platform still feel reliable when you move beyond one small server into storage, networking, backups, and more serious workloads?
That is the more useful question.
At Raff, AMD EPYC is part of a larger infrastructure philosophy: build on modern hardware, keep the platform understandable, and let the layers above it grow in the right order. If you want to see how that shows up in practice, start with Linux VMs, then look at how the rest of the platform connects through object storage, private networking, and data protection.
That is where the decision makes the most sense.
Not as a chip choice in isolation.
As part of the kind of cloud platform we are trying to build.