Thanks for doing that comparison and providing some real-world figures.
Just to confirm, when you're testing with RDS, is your Moodle instances on AWS in the same region?
I'm not sure that it's fair to compare an AWS RDS db.t2.micro against a server which you've specifically tuned. As you can see from the Product Details page, the Micro is a low-powered machine, much like the Pi, but it's also a Burstable instance.
Burstable instances are cheap, low-powered, shared infrastructure instances. They are designed for small, and inconsistent workloads. They have a total of 1vCPU, and 1GB of RAM available to them, but that CPU is burstable meaning that it is over-allocated. Baseline performance is only a fraction of that vCPU (This blog about EC2 Burstable instances explains how it works a little). You earn AWS credits for each hour that your machine is idling, and you spend those credits when you ask the CPU for more than your baseline performance. If the RDS baseline is inline with the EC2 baseline, then you have a 10% share of a 2.25Ghz processor.
Meanwhile your Raspberry Pi is a quad-core machine. Yes, it has a slower clock-speed at full-speed, but unless you're under-clocking the machine you always have access to all of that clock-speed. It still has four cores and can multi-task more efficiently.
The other thing to bear in mind with AWS services is that they are managed, and easily upgradable depending upon requirements. Multi-AZ replication is available very easily, as are guaranteed IOPS SSDs. Yes, these features cost more money, but you're also highly unlikely to run a service for 1500 students on a Raspberry Pi. You can buy bare-metal hardware and run with that, but the RDS instances have automatic host replacement upon hardware failure, and automatic software patching. You can still tune an RDS instance, just like you can a bare-metal.
Just for information, all of the MoodleCloud infrastructure is hosted using Postgres RDS instances.