But which plan to get?
No one can answer that for you. Every app has it's own requirements and complexities.
Let's just take the homepage as an example. If on my site, I only need to do a single database query to retrieve a single record...it would be pretty fast and not consume very many resources. Maybe it only took 5 Megs of ram to do.
But maybe your app has 20 complex queries, doing aggregate calculations and stuff, as well as hitting an external api to retrieve data, using collection filters on the results, etc. That might take 10x the resources (cpu/memory) as my homepage. Maybe it took 80 Megs of ram to do.
Now, contrast that with everything else your app does. Then take into account how many simultaneous users there are. Each app has different requirements, as they (probably) differ greatly in what they're doing. So, there isn't a single universal answer.
So, I'd probably start off with a mid-range server. Don't make it live. Run benchmarks on it using tools that will simulate a user load by hitting different pages as fast as it can until it starts timing out. That will give you an idea on what kind of load the server can take running your app. Maybe you'll be able to handle 1000 concurrent connections. If not, use the number the tests show on how much larger of a server to try next. Then destroy the old server, build a new one with more horsepower and try the tests again. If your goal is 60k simultaneous users, you should probably shoot for 20% over that.
If you're expecting that many users, it would probably be better to use a load balancer and many smaller app servers. It also eliminates a "single point of failure". Like, if you have 1 server and something happens to it, then everybody is blocked from using it. If you have multiple app servers and a load balancer to distribute the load, it's less of a problem if one goes down. The app will still be accessible.
