How do you know that AWS/GCP can't trace it back to you?

They probably can as I've (hopefully) implied in my comment. When I sign up for AWS/GCP for a bit more credits for free, I use a burner phone (if necessary), burner emails (catchall emails), and a debit card (although GCP and AWS can detect if you're using one made by privacy.com or DoNotPay... so I have to call my bank and get one every now and then).

Given this relatively bad information, it's somewhat hard to trace. But as I've said: Government surveillance is government surveillance. These petty tactics to get around AWS/GCP won't cut it. Pretty sure they'll call up my bank using the card details and get my info real fast.

Do you still give them your real name and billing address?

My AWS billing address was a largely abandoned factory, not far from Veliky Novgorod.

Me too, think.

What about sharing it as an internal non-exit VPN in a nested chain?

Can you elaborate? Not sure what an internal non-exit VPN nested chain is... although I some vague idea on what that may constitute to be.

In this diagram, VPN1 is what I'm calling the "internal non-exit VPN": https://keybase.pub/mirimir/VBox-Two-VPNs.png

It's not as much "non-exit" as Tor middle relays. Because it just connects to the VPN2 server using OpenVPN over standard TCP/IP. Instead of some proprietary protocol. But at least it's locked down with pf rules, so that it can only connect to the VPN2 server.

The diagram shows a nested chain with just two VPNs. But you can add more layers. As I recall, as many as six or so. Latency goes up, and MTU goes down. But throughput doesn't crash as much as you might think. I don't know why. But maybe it's caching.

So basically, you have a NAT chain locally in VirtualBox or whatever. And each NAT router includes a remote VPN server.

In order to share it, you'd need to open a port for incoming OpenVPN connections. Either locally, or forwarded to one or more VPN servers. And then you could route traffic through another VPN server in the chain.