I don't think you need multiple ASNs for this. The "server" end handles this; if your packet bound for 8.8.8.8 leaves Starlink's network in Tulsa, then you get 8.8.8.8's server in Tulsa (because that is the route that Google advertised to Starlink at that PoP), then the 8.8.8.8 server in Tulsa talks to your own DNS server in Houston, and you only serve the IPs for your Houston datacenter in that reply as a matter of policy. (You might not run the DNS server, of course, but that's what, say, Cloudflare would do for you.) Then an Internet-wide route controls further traffic; if Starlink decides to make that customer's traffic egress in New York, then that packet is stuck going cross-country. It doesn't have to be that way; you could host your personal website on anycast if you wanted to, but it's a lot of work. You don't need an ASN per datacenter, though, you just need to control your route advertisements on a per-datacenter basis.
GeoIP is a further complication not really related to the Internet. The DNS server in Houston can serve replies for packets coming from anywhere in the country; instead of looking at what network interface they arrived on, it looks in a database, decides 1.2.3.4 is in Oklahoma, and provides IP addresses for the Houston datacenter because of that. For Starlink to provide the best path in that case, it needs to understand what that database looks like; it's likely they populate it themselves in a protocol outside from any Internet machinery. (The most naive databases just look at the ASN of the source address, look at where the address of the ISP is, and decides that's the location of the IP address. But that is too naive to work, so nobody does that exactly.)
I would imagine that most of the CDNs / edge compute providers use some combination of these two data points to route traffic. I have never set anything like this up, so I'm not sure what the state of the art is. But, there are many tools that you can use, and none of them require having an extra ASN.
When I worked at an ISP we did some somewhat-sketchy management around this. The databases often have a flag for "is this address a cloud provider or a residential ISP subscriber?" We would see which of our IP ranges were considered residential (we had 0 residential customers), and then use them for IP transit subscribers that wanted to sell services like scraping Amazon or whatever. Amazon would check their database, say "oh this is just a virus-infected cable modem", and allow the traffic. If the reputation changed, we could just give the address to a transit customer that didn't want to do that kind of stuff. Just going to say, I played no part in this business decision; it existed when I arrived and existed when I left. Gotta pay back the investors somehow, I guess!
(At my next job I was on the other side of this; trying to combat free trial abuse. The databases were largely useless; what happens is that people at high-reputation ISPs get their servers hacked and the attacks end up launched from there. The big cloud providers were like 100% abuse traffic, probably because of free trials of CI systems and things like that. Ultimately, most traffic going through a US-based transit provider got "please contact sales to do a free trial". Actual residential ISPs like Comcast were totally fine; thanks Windows Update! Since it was the pandemic, everyone was working from home, and thus the business ISPs being gated behind "talk to sales" were not a big problem. Oh and BTW, I am certain that most of the abuse was from HN readers; it started the day after we mentioned our product here. That cat and mouse game was some of the most fun I've had at work!)