There's the opportunity cost to throwing away your organization's knowledge of AWS, though. Everyone will have to learn to do things the bespoke way on your bare metal. So developer productivity could decline.
I would say the exact opposite in some ways for teams who are not using AWS yet. My team for example has been operating bare metal for 8 years now, and we know how to do that. Transitioning our team to the "bespoke way" that AWS does things has a huge opportunity cost, too.
This is where Kubernetes I think helps a ton. I work with bare metal customers all the time that stand up OpenShift on their BM and can migrate k8s apps very easily. Depending on the apps you may need to throw an object storage solution in there too (such as OpenShift Container Storage). It does require a certain scale before this makes sense, but it's not nearly as high of a scale as most people think.
You go on to AWS for their managed services like Fargate, DynamoDB, ECS, S3 etc. Have used OpenShift in the past and had endless problems with cluster stability (especially in 3.x), and weird inconsistencies.
With AWS I could just spin up 10 Kubernetes clusters with pretty much unlimited resources, can't do that in OpenShift because you'd hit a resource quota or limit.
Imo using cloud vendor apis is more bespoke than using kube/nomad or even old school andible/salt on baremetal cluster. With the exception of s3 all your knowledge will tabled if ever need to switch the vendors