Cloud vs. on-prem

Where your app runs decides who owns the machines, who can touch the data and who has to defend it. The cloud hands much of that to a provider; on-prem keeps all of it, the good and the bad, inside your own building.

Two ways to run the same app

When you deploy to the cloud, you rent computing from a provider such as AWS, Microsoft Azure or Google Cloud. You ask for a virtual machine, a database or a storage bucket, and minutes later it exists. The servers, the data centre, the power and the cooling all belong to the provider, and your workload shares that hardware with other customers, kept apart by software.

On-premises, usually shortened to 'on-prem', is the opposite. Your organisation buys the servers, racks them in a room or data centre it controls, runs the network and keeps the keys to the door.

The app itself doesn't have to change: the same code can run in either place. What changes is who owns each layer underneath it.

Why the cloud is the default

For most teams the cloud wins, and for good reasons:

• Speed. A new environment is an API call away, not a purchase order and a delivery date.
• No upfront hardware. You pay for what you use, instead of buying servers sized for your busiest day.
• Elasticity. Capacity grows when traffic spikes and shrinks when it drops.
• Managed services. Databases, queues and backups come ready to run, patched by someone else.

The trade-off is control. You can't walk up to the machine your data lives on, you rely on the provider's own security and uptime, and a large, steady workload can end up costing more than owning the hardware would. For a start-up, a side project or most web apps, that trade is well worth it.

Why some organisations keep it in the box

Banks, hospitals and government bodies often make the other choice. Their reasons are rarely about technology alone:

• Regulation. Rules in finance, healthcare and the public sector can restrict where certain data is stored, who may process it and how it is audited. Meeting them is simpler when you can point to the exact building.
• Data residency. Some data must stay within a country or region. Cloud regions help, but some organisations want a guarantee they control, not one they read in a contract.
• Control and visibility. Owning the servers and the network means knowing exactly where the data sleeps and exactly who can reach it.
• Existing systems. Older core systems, such as a bank's ledger, were often built to run in-house and are hard to move.

None of this makes on-prem more secure by default. It makes it more controlled. Whether that control turns into security depends on how well the owner uses it.

What owning the box costs you

Cloud providers describe security as a shared responsibility: they secure the data centre, the hardware and the virtualisation layer, and you secure what you run on top. On-prem, there is no one to share with.

Here is who looks after each layer when you run an app on virtual machines:

With managed services the provider takes on more, such as patching the database engine. But the bottom row never moves: your app and your data are always yours to protect.

On-prem adds everything above that row. Someone has to replace failed disks, patch every server, control who walks into the server room, plan capacity years ahead and keep backups somewhere a fire in that room can't reach.

Attackers still show up

A common mistake is to treat 'inside our building' as 'safe'. Attackers don't need to walk through the door. They get in the same ways they get in anywhere else:

• a customer-facing web app with an injection flaw or broken access control;
• an unpatched server, because patching is now your job;
• a phished employee whose laptop is already on the internal network;
• a firewall rule that was meant to be temporary.

Once inside, an attacker can hop from machine to machine, which is called lateral movement. That is why a flat internal network, where everything can reach everything, is so dangerous. On-prem gives you the power to split that network into tightly fenced segments. It doesn't do it for you.

Testing your own defences

The only way to know whether your defences hold is to attack them yourself, with permission. That is penetration testing, or pentesting: a tester plays the attacker, looks for weaknesses, tries to exploit them and reports what worked, so it can be fixed before a real attacker finds it.

The gap between tests

Traditionally, a pentest is a scheduled project. An outside team spends a week or two on your systems, often once or twice a year, and hands over a report.

The problem is everything that happens in between. Code ships every week, new servers appear, and a firewall rule changes on a Friday afternoon. A test from last spring says nothing about last night's release.

Continuous testing closes that gap by attacking your systems all the time, so a new weakness is found soon after it appears rather than months later. Autonomous tools go further than a scanner working down a checklist: AI agents plan and run the attack more like a human tester would.

The on-prem catch

Many automated testing tools run as cloud services. They send your code, your traffic or their findings to the vendor's servers, or to an outside AI model, to do the analysis. For a team that chose on-prem so its data stays in the box, that defeats the point.

The answer is to bring the tester into the box too. The video shows one example, Aikido Machine: a server with GPUs that sits inside the organisation's own network and runs autonomous pentests all day, every day, with no cloud API and no outside model.

That matters more than it sounds. The testing stays in the building, and so does everything it learns. A list of your unfixed weaknesses is some of the most sensitive data you have.

A worked example: one bank, two apps

Picture a bank starting two projects.

The first is a marketing site: product pages, interest rates, a branch finder. None of it is private, and traffic jumps whenever a campaign runs. This is a natural fit for the cloud: ship quickly, scale with demand, and let the provider handle the hardware.

The second is a ledger service. It records who owns each account's money, every transfer between accounts, and each balance right now. It holds regulated customer data, and the compliance team needs to know exactly where that data is stored. So the bank runs it on-prem, in its own data centre, on a network segment that only the services needing the ledger can reach.

Choosing on-prem is only the start. The team now owns the patching schedule, the backups, the door access logs and the monitoring. And because the ledger's API changes with every release, a yearly pentest isn't enough. They run continuous testing from inside the same network, so a broken permission check shipped on Tuesday is found that week, and no detail of the ledger ever leaves the building.

Most real organisations look like this bank: some workloads in the cloud, some on-prem, joined carefully. That mix is called hybrid, and it is far more common than going all-in on either.

Common mistakes

• Treating on-prem as automatically safer. Control only helps if you use it: patch, segment, monitor and test.
• Assuming the cloud provider secures everything. The provider secures its layers. Your configuration, identities and data are still yours.
• Testing once a year. A pentest is a snapshot. Systems that change weekly need testing that keeps up.
• Sending on-prem data out to be tested. If data must stay in the box, check where your security tools send it.

Key takeaways

• The cloud rents you someone else's machines; on-prem means you own the machines, the network and the building.
• The cloud is the right default for most apps: fast, elastic and low on upfront cost.
• Banks, hospitals and governments often choose on-prem for regulation, data residency and control.
• Owning the box means defending all of it, because attackers still find ways in.
• Continuous pentesting run inside your own network keeps the testing, and its findings, in the box with the data.