As someone who helped design the Cloud SQL VM environment, I can corroborate with the OP that it is utterly boring :) I left that team some time ago, basically after we launched this architecture.
When we wrote it we really were just using VMs as originally provisioned by Google Compute Engine and shoving MySQL as a Docker container and an API communication layer as a Docker container too. We deliberately wanted it to be as boring as possible partly for security concerns. The blast radius is pretty small when all you can do is compromise your single-tenant VM.
Obviously nowadays instead of single-tenant VMs you’d do this with Kubernetes. We were about two years too early.
My pet peeve is when people write blog posts and the use “fake” IP addresses such as 123.XXX.XXX.XXX in this blog post. There is a defined documentation IP address block, please stick to these IPs when writing up results. You wouldn’t want your own IP ending up there and getting targeted by scrapers/bots, would you?
That aside this is a very interesting write-up!
For a long time, an (inane) Tweet of mine got replies and retweets from people I didn’t know, for no apparent reason. I could never figure it out.
Years later, I found out that the URL was somehow included in Twitter’s official documentation, and people were replying to it when they couldn’t figure out API stuff.
Use the defined examples (or at least your own targets), indeed, please. (-:
Feeding any such bots random IPs sounds like a public service. After all they are perfectly capable of generating random IPs themselves so you can’t be helping them, and they are going out of their way way to not just use random IPs so you are probably hurting them.
Wouldn’t it be even better if the IP didn’t actually exist? I see absolutely no reason to choose a random IP over the documentation IP.
It’s easy to filter for the official documentation IP, especially if everyone uses it. Same with any other private range/loopback/whatever.