I get asked some version of “should we move the database to the cloud for DR” more often than almost any other question, and I’ve started answering it with a different question entirely. Not because I’m dodging it — because it’s genuinely the wrong first question for most of the teams I work with.
The question that actually matters is: how much resilience can we honestly afford to build and, more importantly, operate?
Big enterprises get to skip a lot of this thinking. Multiple regions, multiple data centers, dedicated DR staff, a cloud budget that doesn’t blink. I’ve consulted for exactly one client like that in my career. Everyone else — most of my clients, frankly, across banking, telecom, and government work in South Asia and a few African markets — has one primary data center, a lean infrastructure team, and a CFO who wants to know why DR needs to cost anything at all. For that second group, DR stops being a technology decision and becomes a trade-off between cost, complexity, what you actually need to recover, and what your team can realistically run day to day.
Numbers Before Platforms
Before anyone shows me an architecture diagram, I want two numbers on the table.
How much data can the business genuinely afford to lose — that’s your RPO. And how fast does the service need to come back — that’s RTO. I’ve sat through more DR workshops than I can count where nobody in the room had actually agreed on these before jumping straight to “so, which cloud?” That’s backwards. If the business needs near-zero data loss and a recovery measured in minutes, you’re paying for that, and paying a lot. If a few hours of downtime and some acceptable data loss won’t sink the company, you don’t need the expensive architecture, and building it anyway is just wasted budget.
The Case for Staying On-Prem
I’m not against on-premises DR — far from it. When an organization already has the infrastructure sitting there, it can be genuinely attractive. The team already knows how the network behaves. The security processes already exist and are already approved by whoever needs to approve them. Costs are predictable in a way cloud billing sometimes isn’t. And you have direct physical control, which matters more to some regulators and boards than engineers always appreciate.
But a second physical site isn’t free, and it’s not just the hardware bill. You need the storage, the connectivity, power, cooling, physical security, monitoring, ongoing maintenance — and then, the part everyone underestimates, someone has to actually run the thing. I’ve walked into more than one “DR site” that hadn’t been failed over to in over a year. That’s not a DR strategy. That’s an expensive backup nobody trusts.
Where Database@AWS Actually Fits In
Oracle Database@AWS gives teams another real option, and it’s worth taking seriously — but not because “cloud” is automatically the better word to put in a slide deck. I’ve seen that reasoning used to justify some genuinely bad architecture decisions.
The question I actually want answered is narrower: does this specific architecture meaningfully improve our ability to recover, enough to justify what it’ll cost us in money and in operational complexity? Sometimes yes. Sometimes the honest answer is no, not yet, not with this team.
Don’t Forget the Network Sits in the Middle of All of This
Any hybrid DR design leans hard on the network connecting the two environments, and that dependency deserves real scrutiny rather than an assumption that it’ll “just work.” I want to know the actual latency and bandwidth between sites, how routing behaves, whether DNS cuts over cleanly, what the firewall rules actually allow, whether the application can genuinely reach the DR side, how monitoring extends across both, and who has administrative access when it matters most.
Here’s the failure mode I’ve actually seen happen: the database comes up fine on the DR side, technically healthy, passing every check — and the application still can’t talk to it because nobody validated the network path end to end. At that point it doesn’t matter that the database survived. The service is still down.
Cost Is Never Just the Infrastructure Line Item
I see this mistake constantly: comparing two DR options purely on hardware or instance pricing. The real cost is infrastructure plus networking plus ongoing operations plus licensing plus the skills you’ll need to hire or train plus the testing you’ll actually have to keep doing.
A cloud DR setup can look genuinely cheap right up until you add data transfer charges, connectivity costs, monitoring tooling, backup, security controls, the operational effort of running it, the cloud skills your team doesn’t currently have, and the cost of testing it properly and repeatedly. Meanwhile an on-prem site can look expensive purely because the hardware line item is visible and upfront, even though the organization already has the people and the building to run it at close to zero marginal cost.
Cheap Isn’t the Same as Low-Cost
Say Architecture A has a lower sticker price but needs specialized skills nobody on your team currently has. Architecture B costs more upfront but your existing DBA team can actually operate it without a six-month ramp-up.
I’d pick B most of the time, and I don’t think that’s controversial once you say it out loud — though plenty of procurement decisions get made the other way, purely on the number at the bottom of a quote. Complexity isn’t free just because it doesn’t show up on an invoice. Every additional piece of unfamiliar technology drags in training, new documentation nobody’s written yet, another thing to monitor, another vendor to depend on, and another way for a 2 AM incident to go sideways because nobody’s confident troubleshooting it.
A Rough Comparison, For What It’s Worth
| Factor | On-Prem DR | Oracle Database@AWS |
|---|---|---|
| Initial infrastructure | Higher | Potentially lower |
| Physical site dependency | High | Lower |
| Network dependency | Medium | High |
| Cloud skills needed | Lower | Higher |
| Existing DBA familiarity | Often high | Depends on the team |
| Scalability | Limited by your hardware | More flexible |
| Operational complexity | Familiar territory | Potentially higher |
| DR testing discipline | Depends on the org | Depends on the org |
| Cost predictability | Generally high | Usage-dependent |
I put that table together mostly to make one point: almost every row says “depends,” and I mean that honestly, not as a cop-out. There’s no universal winner here, and anyone who tells you otherwise is probably selling something.
Bring the Application Team Into the Room Early
A database that fails over cleanly is only half the story. If the application can’t recover alongside it, you haven’t actually achieved DR — you’ve achieved an expensive database that happens to be running somewhere else. I make a point of pulling in application owners, network and security teams, whoever owns DNS, infrastructure, and the DBAs, and testing the whole service end to end, not just the database tier in isolation.
Actually Walk Through the 2 AM Scenario
Every DR design needs to survive one honest exercise: what actually happens at 2 AM if the primary database goes down. Not in theory — walk it through, step by step, out loud, with the actual people involved.
Who gets the alert, and are they even reachable at that hour? Who has the authority to declare this an incident and not just a blip? Who’s actually activating DR, and do they know how without calling someone else first? How does the database get opened on the other side? How does DNS get updated, and by whom? How do application connections get redirected — automatically, or does someone need to flip a switch? How do you tell users what’s happening, if anything? And once the dust settles, how does the primary environment actually come back?
If any of those answers is a shrug, the DR architecture isn’t finished, no matter how clean it looks in the diagram.
Final Thoughts
For teams without unlimited budgets — which, in my experience, is most teams — DR isn’t about buying the most impressive technology on the market. It’s about hitting the recovery objectives you’ve actually agreed on, with an architecture your own team can operate without outside help every time something goes wrong.
Oracle Database@AWS is a strong option for plenty of organizations. On-premises DR remains the right call for plenty of others. I genuinely don’t think one universally beats the other — the winning architecture is whichever one actually delivers your required RPO, RTO, security posture, and cost profile, run by people who understand it.
The best DR strategy was never the one that photographs well in an architecture review. It’s the one that still works at 2 AM, when nobody’s in a good mood and the primary environment is down.
Comments 1