That's actually a pretty bad setup. You are making it over complicated to the point where what you view as defense in depth is actually extra attack surface. For example using a VPN defeats Tor's guard rotation algorithms, which are fine-tuned to reduce the chance that you hit both a malicious guard and exit at the same time.
Using bridges when you are not being blocked by censorship is also a very bad idea It reduces the amount of possible entry points you can blend in with. Bridges are so ubiquitous that chances are, you would be one of the only if not the only person to use that bridge at any given time. That makes traffic correlation attacks much eaiser when an adversary does not have to demultiplex communications from the guard (or bridge) to the middle node. Think about it this way: if you are the only one using the bridge, then is there any doubt that the traffic going from the bridge to the middle node is not yours? Now, if you are using a popular guard, much more work would have to be done to correlation which stream of traffic is yours and which is just noise from other users.
Additionally, you say you change bridges frequently. Just as with changing guards, that is a VERY BAD idea. The first node in the Tor circuit should be long lived. In fact, Tor Project rather recently changed guard parameters to make it even more long lived, because even changing every few months was too quick, and made deanonymizing sybil attacks significantly easier. Their modification of the parameters to keep a single guard for a year or more has made sybil attacks, and other types of traffic correlation attacks much harder. Search the Tor Project blog for "tor guard parameters" for more information on the mathematics behind that.
Logs are kept on your VPN. Just because the VPN service claims not to log does not mean their upstream ISP (which is in all likelyhood something like OVH) does not either. If the upstream ISP logs, which it certainly does, then the claim that your VPN does not log becomes moot.
Using CCleaner is often quite useless. Modern filesystems which are either journaling filesystems (like ext4, jfs, etc) or copy-on-write filesystems (like NTFS, which is partial CoW, btrfs, or zfs) cannot have files or even free space reliably erased. Furthermore, many VM virtual hard disk formats are CoW anyway, so even if you switched to FAT32 or something, it would still not end up being quite useless.
The unnecessary use of VMs and RDP also add to attack surface area. Furthermore, on all x86 and most ARM hardware, it is quite trivial to mount side-channel attacks from within a virtual machine. These attacks are capable of reliably detecting what phrases are being typed on the host, and can even steal keys from the memory of certain insecure cryptographic applications. The attacks that can do this reliably are named prime+probe, flush+reload, and flush+flush, named in order of stealth and efficiency. Furthermore, virtual machines still expose low level hardware to the guest, and trivial escapes are not uncommon at all.
All in all, your setup makes it easier both to deanonymize you from the outside, but also from the inside, by exposing the huge attack surface area of RDP and VMs. I would very, very strongly urge you stop this setup and instead use Tails, or even just Tor Browser on Debian.
Before you try to do anything like this again (creating your own complex setup), first formalize your threat model. Information on threat modeling online is ubiquitous. Until you do that, using Tails is almost always a safe bet for anonymity.
