Notes from a session I co-presented with TaylorMade's infrastructure team — the decisions that shaped it, and why they still matter.
On stage at AWS re:Invent, Las Vegas — with Chris Smith, Manager of Infrastructure Engineering at TaylorMade Golf.
A few years back, I co-presented a session at AWS re:Invent with Chris Smith, who ran infrastructure engineering at TaylorMade Golf. The topic was Oracle ASM on AWS and specifically, how TaylorMade had migrated their disaster recovery environment to AWS and what it actually took to get Oracle running correctly in that context.
re:Invent is a different kind of audience. Fifty thousand people, a lot of them deeply technical, most of them with a low tolerance for vendor theater. If you're going to put a customer on stage, the story needs to be real with the problems, the wrong turns, the actual outcome.
Here's what made it worth talking about, and why I think it's still relevant.
The Setup
TaylorMade is the largest golf equipment company in the world. At the time, they were owned by Adidas, and Adidas had asked them to cut costs — specifically on their disaster recovery infrastructure, which was sitting in a server room with the usual hardware overhead and refresh burden.
The requirements weren't complicated on paper: move DR to the cloud, cut CAPEX, keep a 4-hour RPO and RTO, handle about a terabyte of daily data changes. Their EBS system is the enterprise business system that runs the company and it needed to be recoverable within that window. Not theoretically recoverable. Actually recoverable.
Why RDS Wasn't the Answer
The obvious starting point for running Oracle on AWS is RDS. Managed patching, automated backups, multi-AZ, no dedicated DBA required. It's a reasonable default for a lot of workloads.
But TaylorMade's DR architecture was built around Oracle Data Guard with a replication stream from their on-premises primary database to the DR target. And RDS can't be the target of a Data Guard stream. That's not a configuration limitation you can work around; it's just not supported.
So EC2 it was. Full control of the OS, the database configuration, the licensing model and the full management responsibility that comes with it. The team went in knowing what they were signing up for, because the alternative didn't meet the core requirement.
That trade-off of managed service convenience versus architectural control comes up on almost every enterprise cloud engagement. The answer isn't always EC2, but the question always has to be asked before you commit to a direction.
The Parts Nobody Warned Us About
Getting Oracle ASM running on AWS was where the project got genuinely messy.
The first problem was the OS. Standard AWS Linux wasn't supported by Oracle for ASM installation — it's not on Oracle's approved list, which matters both for licensing and for getting support if something breaks. The fix was straightforward once you knew it: use Oracle Linux AMIs instead. But it's the kind of thing that catches teams who assume AWS Linux is the right default everywhere.
The second problem was storage. In an on-premises SAN environment, requesting dozens of LUNs for ASM disk groups is routine. On EC2, you're capped at 20 EBS volumes per instance. That's not a lot when you're used to thinking in terms of hundreds of LUNs. It forced a different approach — one disk per ASM disk group, no partitioning — which works fine once you've adjusted, but getting there requires you to actually let go of how you've always done it.
Neither of these problems is exotic. Both are the kind of thing you figure out at 11pm when you expected to be done by 3. They're also the reason experienced Oracle-on-AWS architects are what can differentiate service providers.
What TaylorMade Actually Got
The project delivered:
30% cost reduction versus the old hardware-based DR setup
Verified recovery within the 4-hour RPO/RTO window
An AWS foundation TaylorMade could build on for future cloud work
Datapipe managing and validating the environment on an ongoing basis
What Chris said on stage has stayed with me: the EBS system is the lifeblood of the company. Every architecture choice in this project — EC2 over RDS, Oracle Linux, the storage redesign — traces back to that one sentence.
What Still Applies Today
The specific AMI versions and licensing details have moved on — AWS's Oracle support is considerably deeper now than it was when we did this work. But a few dynamics haven't changed.
The managed-versus-control question doesn't go away. It just shows up wearing different clothes — RDS vs. EC2 in 2015, managed Kubernetes vs. self-managed clusters today, SaaS AI platforms vs. custom model deployments tomorrow. The form changes; the trade-off doesn't.
Enterprise software licensing still bites people who don't account for it early. Oracle and SAP impose constraints on cloud deployments that don't automatically align with a cloud provider's default setup. That gap between what the vendor supports and what the cloud provider offers out of the box has to be closed deliberately, before the architecture is locked in.
And on-premises storage assumptions still don't travel well. The mental model built from years of SAN environments — request what you need, partition how you like — doesn't map cleanly to cloud storage. Teams that treat it as a direct translation rather than a redesign tend to find out the hard way.
On the re:Invent Experience
The thing about that audience is they can tell when a case study has been sanitized. What made the session work wasn't necessarily the outcome — it was being able to explain why RDS was the wrong call, what the Oracle Linux issue actually cost in time, and how the storage approach had to change. The credibility came from the friction, not the just the results slide.
That's still how I approach technical storytelling in advisory work. The architecture diagram is not always (but maybe sometimes) the interesting part. The interesting part is everything that had to get decided before anyone drew it.
David Lucky is the founder of CloudScale Advisory. He works with cloud, AI, and enterprise technology companies on GTM strategy, product marketing, and partner ecosystems. He previously held senior roles at Datapipe, Rackspace, Effectual, and Centrilogic.
Interested in discussing a cloud, AI, or GTM strategy initiative? Get in touch.