As for Ingress, Amazon does have an ingress controller that configures an Application Load Balancer with kubernetes Ingress API objects. I feel like this locks you in less because again, Ingress is standardized. The problem with Ingress specifically is that the standard doesn't cover things people actually want their ingress controller to do, so every implementation has their own set of features. We use nginx... you better believe there are literal nginx.conf snippets inside the Kubernetes API objects to get things to do what we want. So this is just a case of Kubernetes being bad, not really cloud provider lockin. I'm more stuck on nginx than on Amazon.
(As for load balancers; again, Amazon has proprietary configuration parameters that won't be portable, but they don't really do anything important. You can make your Amazon load balancer terminate TLS (a bad idea), and pick which of the 3 Amazon load balancer types you want to use. Switch to Google, and that won't work... but you also probably won't care. The Load Balancer API spec seems to do what people want, so it's relatively commoditized and you won't be sad when you switch providers. We actually have to have a wildcard certificate specifically because Amazon's classic load balancers are so bad. Would be happy to not terminate TLS in the load balancer and have Envoy or Nginx terminate TLS and ask letsencrypt for a new certificate every couple months.)
If I use DynamoDB, I'm stuck with AWS, absent an expensive, difficult migration.
Even with Kubernetes, moving from EKS to your own cluster means spinning up your own k8s masters, which might not be in $RANDOM_DEVELOPER's wheelhouse. And IIRC AWS has their own special things for doing ingress that you'd need to change as well.
Even just going from EC2 to Google's analog might mean rewriting private tooling that specifically uses AWS APIs.