There's no formula, because the workload is as much a function of your code as it is about the number of concurrent users. If you are using caching properly an S will be sufficient for "web" but not "master". If you have a logged-in area you will load up "core" as well.
My suggestion is to start with S3 for master and web, and monitor the DTU, CPU, IO and connection telemetry during peak operation, and during publishing. There's graphs in the portal.
If you rarely hit 60-70% then turn it down to S2. There's a big drop to S1 stop don't be tempted by that. Remember you can change these scales in about an hour with virtually no disruption to traffic. Write a powershell script and run it on a timer to scale up/down at 2am or whenever your site is quiet.
EDIT: Forgot to mention that at the moment all our deployments are done with SQL Elastic Pools instead of individual databases. This has the advantage that you can 'thinly provision' resources to the environment, knowing that while individual databases require burst capacity, they don't all need it at the same time.
Our current starting setup is a Standard 100 eDTU pool for non-production (including Core/Master/Web/Analytics) and Premium 125 eDTU pool for production.
I'm still on the fence on whether a P125 is better than a S200 for 40% extra cost, but 35% less eDTU. We're still evaluating that. The main difference is that with the Standard pool each individual DB is capped to 100 eDTU, which is not the case on the Premium tier.