To get a general sense of I/O speed on the disks, you can perform any of these disk-intensive maintenance tasks. Note that these won't really help if you're trying to test for a specific workload, but if you're purely interested in disk I/O driven by T-SQL commands only, this is a good "easy" solution.
Create or Rebuild Indexes
This will give you both reads and writes, as tables will be scanned, and then written to new indexes in the specified index order. This is probably most helpful if you can do it on tables with lots of rows, or big data types.
DBCC CHECKDB on a database will generate a large amount of reads, as it's checking for corruption throughout all of the indexes and tables in the database. Since you're on 2008 R2, which doesn't have parallel CHECKDB, the utility of this option might be limited.
If you weren't on RDS (which restricts backups to be performed to S3 through a wrapper stored procedure), running a native SQL Server backup would be a good option to push read and write I/O.
You may still be able to test read I/O by backing up to the
NUL device. See
BACKUP (Transact-SQL), and especially:
The NUL device can be used to test the performance of backups, but should not be used in production environments.
The general approach with any of these solutions would be to get a before and after from
sys.dm_io_virtual_file_stats. There is an example of how to do that in the Paul Randal blog post you linked to in the question.