Your colo provider should be doing their part for physical access for ISO27001/SOC2 and PCI-DSS.
I quite literally know all about this because I was running payment card infrastructure in a colo, as part of one of the largest e-commerce software suites in the UK at the time.
Cloud gives you direct access to compute at the click of a button (provided you have quota).
The ISO/PCI cert requirements are not accelerated by their use, only the initial deployment speed of your solution. If at all anything the latest I've seen is that there are more checks in cloud for various areas where you can accidentally leak data through poor permissions or because someone could enable those permissions.
For example in Google Cloud there was an additional requisite that I monitor any admin users oauth2 application accesses for their google accounts; this was not a requirement for on-prem.
At least in my experience as a service provider.
With cloud I can easily plug in a compliance vendor like Drata, add connectors to my other vendors, and get a significant amount of evidence quickly.
Bespoke on-prem solutions bring plenty of their own challenges that are just N/A or handled by cloud vendors, like physical security.
Maybe as a payment processor things shake out differently. Though having read far more of PCI v4 than I'd like, I doubt it.
Do you trust your people to never slip up? To make sure there's really the reliability & security guarantees that your company depend on? Are there competent technical hands available at all times to handle issues as they come up? This adds significantly to the org chart, requires constant caring to be added, to keep it steered and staffed.
I'm a huge fan of self hosting, of buying your own hardware. Especially for very technical entities, that have lots of overlap & intimacy with computers. But your company needs to have reason to believe it can do the job not just well, but to a degree where you're sure you won't lose the entire business. Needs to believe they really are on top of this huge domain! I see very clearly why folks go cloud, and I wish the world was in a better position, had more to say, to show why buying pizza boxes is gonna not just save you money buy be an enduring acceptable safe choice.
Much safer to not wade in here, shutting the hell up is free, and there's plenty that can go wrong, but I do think Kubernetes presents the first maybe acceptable opportunity for broadly acceptable DIY computing, delivering key three things: an essential integrativeness of concerns allowing it to be a comprehensive cross-cutting platform for your business's compute, delivers strongly on the security and dependability you absolutely must have in a well known way, and avoids the historical trap of each company ending up married to their own specific boondoggle infrastructure that's been hand cobbled together by whomever had such and such task at the time. There's a stable practice here, one that many companies and practitioners are honing; there's much difference between Kube clusters sure, but these intracacies and elaborations support the creation of something that is mostly alike, if you look from one company's clusters to the next.
Would UniSuper engineers have trashed their entire infrastructure the way Google Cloud did? Granted, that's not a common thing to happen, but they got _very_ lucky that day that they had a backup elsewhere and didn't fully commit to trusting Google.
And while your company is a single petri dish with your own specific problems, these folks have to see a lot of shit. Sometimes yes it all goes bad even there anyways! The resiliency fails! But given how much they've thought about it & how much they've hedged against 1 in a million 1 in a billion cases that they see semi regularly that your company might never notice until it's too late, I think there's a ton of reasons to trust these generally very well exercises systems with pretty sizable engineering teams & deployments behind them. More so than what most folks can bring to bear.
These matters are existential threats for your business. And they are existential threats for big providers, for HyperScalers, even more so. Google very publicly owned up to UniSuper, found out why it happened (a blank form on an internal tool lead to the account having a 1 year time limit with auto-deletion), and publicly announced their three fold plan to make sure at least this specific horribly threat would never happen again:
> We deprecated the internal tool that triggered this sequence of events… We scrubbed the system database and manually reviewed all GCVE Private Clouds… We corrected the system behavior that sets GCVE Private Clouds for deletion for such deployment workflows.
https://cloud.google.com/blog/products/infrastructure/detail...
The mere fact that this was such a notable event should be itself notable. In general, the hyperscalers have been stupendously reliable. And absurdly secure. They have small armies dedicated insuring both.
I look forward to this new era where finally we might have computing of our own good enough & broadly known & trusted enough to make doing our own - even with small teams - viable!! But heavens yes, keep off-site backups!!!
Individual AZs have significantly worse uptime than any DC I've ever worked with. They are very reliable, if you are multi-region - and you hire a small army of consultants.
The biggest thing I hear otherwise is "but salaries!". Okay, but you're just replacing your sysadmins with AWS devops people, who I can't imagine are cheaper.
Cloud isn't simple, it's very complex. You need just as many people and just as much knowledge to make it work.
Someone needs to study these claims tbh; your point is contrary to my experience.
You can subsidize the cost of self hosting by discounting your time/skill in DIY - and you don’t have to interview yourself.
You need to do that for cloud as well. The assumption that you can just get the developers to spin up what they need doesn't work. You need a team of "cloud engineers" if you don't want your cloud bill to go crazy. I know a few people that does AWS for clients, they basically spend all their time maintaining, upgrading and reworking things to reduce the cost.
In one example, when AWS changed their IPv4 pricing, one of the went in an managed to remove 90% of their public IPv4 usage. You need to say on top of the cloud platforms, ensuring that costs stay low is a full time job.
However there are SREs and DevOps engineers that are seemingly required for cloud solutions; and they cost more than sysadmins.
So, someone is lying somewhere.
The profession grew out of observations made in catastrophic failures like Chernobyl.
They primarily focus on organization structures, communication structures, and responding to failures. At an engineering level they focus on meta stability - decoupling local failure from overall system stability to prevent local failures from cascading to catastrophic failures - and automated tooling to loop the right engineers into ongoing incidents.
The skill set is a side effect of operating at scale, where even brief catastrophic failures can result in hundreds of millions of dollars of losses; directly in revenue and indirectly to reputation.
You can “buzzword” yourself into job security just as easily on a VM.
People are starting to learn that cloud hosting isn't exactly cheap. It's great for quickly scaling, there's way better automation tools, e.g. Terraform, a lot of the complicated stuff is done for you, but it's not cheap.
37signals is running their own infrastructure, and it's cheaper than cloud.
EDIT: (I can't reply for a bit) Quick glance at https://www.hetzner.com/sb/ seems to suggest 64GB RAM and a full Intel i7.
https://www.hetzner.com/dedicated-rootserver/ax42/
But 8/16 is $95+ on AWS.
That's where they get you.