In what range can you expect a cloud based Sql Server data reading in mb/s?
So measuring if a server can handle your specific workload by the amount of money it costs when weighing different implementation options is as as much of a moot point as measuring how much a car costs when comparing their MPG between different cars to figure out if they can drive you from point A to point B.
My analogy above is meant to convey that we can't really provide a meaningful solution based on $ spent since there are different types of server configurations for the same amount of money, and the same amount of money spent on the server will generally result in the same output performance of any implementation you choose (RDBMS, NoSQL, memory-cached, alternative DB system, etc) for equivalent problems respective of their domain. It is not qualitative enough for an accurate answer to be provided.
That being said, knowing things like how frequently the data is changing, how frequently new data is being added, total size of the Tables and database, and how concurrently active your database will be help paint the picture, which you've provided some of already.
Other things that will be key in helping clarify a good solution for you are what kind of data is it and how is your data structured currently? (E.g. is it highly relational, is it not very concretely defined, is it mixed.) What kind of queries are typical during your off-peak and peak concurrent time-frames? Examples are very helpful here in communicating what your data looks like and what the querying of that data looks like.
For example if your data isn't very well structured / not concretely defined and it's only typically accessed by the key then a NoSQL solution is probably best. If the type of querying your users do is analytical (such as aggregative querying) then it might make sense to scale up a data warehouse or use things built into Azure SQL to improve analytical querying.
Finally I'll add from my previous experience with a not too far off server of similar data size and concurrency, $300 was not enough to support the hardware behind our server. Sure, we definitely could've made some design and implementation improvements, but I still think $300 just wouldn't cut it (for a cloud based solution). I'm going to assume the same will be true for you, but that's a big assumption since my example is only anecdotal and as David Browne mentioned, you're best off testing to see what works within your price range.