You can use read only replicas but they are not frozen so they can receive some new data.
Maybe you can fix the issue with some kind of filter based on insert/update datetime.
Azure SQL Database doesn't support Database Snapshots, so there's no other option besides:
Running the reporting queries in a SNAPSHOT transaction.
Creating a consistent copy of the database with COPY or point-in-time restore.
After experimenting with the example given by Hannah Vernon, I believe I've found the source of my issues with snapshot restore.
In my chase to repro this issue on my box, and in our test suite, we set the restore target database to single user prior to snapshot restore with a statement along the lines of alter database x set single_user with rollback ...
I'm attempting to repro your scenario, and am seeing the snapshot restore time between 600 to 800 milliseconds.
This is the repro:
IF DB_ID('test_snapshot') IS NOT NULL
ALTER DATABASE test_snapshot SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE test_snapshot;
CREATE DATABASE test_snapshot
ON (NAME = '...